home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 8_5_02.tro < prev    next >
Text File  |  1991-12-22  |  120KB  |  5,346 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright (~c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v'|.5i'
  22. .sp 2P
  23. .LP
  24. \fBRecommendation\ X.224\fR 
  25. .RT
  26. .sp 2P
  27. .ce 1000
  28. \fBTRANSPORT\ PROTOCOL\ SPECIFICATION\ FOR\ OPEN\fR 
  29. .EF '%    Fascicle\ VIII.5\ \(em\ Rec.\ X.224''
  30. .OF '''Fascicle\ VIII.5\ \(em\ Rec.\ X.224    %'
  31. .ce 0
  32. .sp 1P
  33. .ce 1000
  34. \fBSYSTEMS\ INTERCONNECTION\ FOR\ CCITT\ APPLICATIONS\fR 
  35. .FS
  36. Recommendation X.224 and ISO 8073 (Information Processing Systems\ \(em\ 
  37. Open Systems 
  38. Interconnection\ \(em\ Transport Protocol Specification) were developed 
  39. in close 
  40. collaboration and are technically aligned, except for the differences noted
  41. in Appendix\ II.
  42. .FE
  43. .ce 0
  44. .sp 1P
  45. .ce 1000
  46. \fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR 
  47. .sp 9p
  48. .RT
  49. .ce 0
  50. .sp 1P
  51. .LP
  52.     The CCITT,
  53. .sp 1P
  54. .RT
  55. .sp 1P
  56. .LP
  57. \fIconsidering\fR 
  58. .sp 9p
  59. .RT
  60. .PP
  61. (a)
  62. that Recommendation X.200 defines the Reference Model of Open Systems Interconnection 
  63. for CCITT Applications; 
  64. .PP
  65. (b)
  66. that Recommendation X.214 is the Transport Service
  67. Definition for Open Systems Interconnection for CCITT Applications;
  68. .PP
  69. (c)
  70. that Recommendation X.213 is the Network Service
  71. Definition for Open Systems Interconnection for CCITT Applications;
  72. .PP
  73. (d)
  74. that Recommendation T.70 defines the Network\(hyIndependent Basic Transport 
  75. Service for Teletex, 
  76. .sp 1P
  77. .LP
  78. \fIunanimously declares\fR 
  79. .sp 9p
  80. .RT
  81. .PP
  82. (1)
  83. that scope, field of application, references,
  84. definitions, symbols and abbreviations are given in \(sc\(sc\ 1 to\ 4;
  85. .PP
  86. (2)
  87. that the Transport Protocol is overviewed in
  88. \(sc\ 5;
  89. .PP
  90. (3)
  91. that the elements of procedure are as specified in
  92. \(sc\ 6;
  93. .PP
  94. (4)
  95. that the classes of protocol are as specified in
  96. \(sc\(sc\ 7 to 12;
  97. .PP
  98. (5)
  99. that the structure and encoding of the transport
  100. protocol data units is as specified in \(sc\ 13;
  101. .PP
  102. (6)
  103. that the conformance requirements are as specified in
  104. \(sc\ 14;
  105. .PP
  106. (7)
  107. that the state table description of the Transport
  108. Protocol is contained in Annex\ A.
  109. .sp 1P
  110. .ce 1000
  111. \fBCONTENTS\fR 
  112. .ce 0
  113. .sp 1P
  114. .sp 2P
  115. .LP
  116. 0
  117.     \fIIntroduction\fR 
  118. .sp 1P
  119. .RT
  120. .sp 1P
  121. .LP
  122. 1
  123.     \fIScope and field of application\fR 
  124. .sp 9p
  125. .RT
  126. .sp 1P
  127. .LP
  128. 2
  129.     \fIReferences\fR 
  130. .sp 9p
  131. .RT
  132. .sp 1P
  133. .LP
  134. 3
  135.     \fIDefinitions\fR 
  136. .sp 9p
  137. .RT
  138. .sp 1P
  139. .LP
  140. 4
  141.     \fISymbols and abbreviations\fR 
  142. .sp 9p
  143. .RT
  144. .sp 1P
  145. .LP
  146. 5
  147.     \fIOverview of the transport protocol\fR 
  148. .sp 9p
  149. .RT
  150. .LP
  151.     5.1
  152.     Service provided by the transport layer
  153. .LP
  154.     5.2
  155.     Service assumed from the network layer
  156. .LP
  157.     5.3
  158.     Functions of the transport layer
  159. .LP
  160.     5.4
  161.     Classes and options
  162. .LP
  163.     5.5
  164.     Model of the transport layer
  165. .bp
  166. .sp 1P
  167. .LP
  168. 6
  169.     \fIElements of procedure\fR 
  170. .sp 9p
  171. .RT
  172. .LP
  173.     6.1
  174.     Assignment to network connection
  175. .LP
  176.     6.2
  177.     Transport protocol data unit (TPDU) transfer
  178. .LP
  179.     6.3
  180.     Segmenting and reassembling
  181. .LP
  182.     6.4
  183.     Concatenation and separation
  184. .LP
  185.     6.5
  186.     Connection establishment
  187. .LP
  188.     6.6
  189.     Connection refusal
  190. .LP
  191.     6.7
  192.     Normal release
  193. .LP
  194.     6.8
  195.     Error release
  196. .LP
  197.     6.9
  198.     Association of TPDUs with transport connections
  199. .LP
  200.     6.10
  201.     Data TPDU numbering
  202. .LP
  203.     6.11
  204.     Expedited data transfer
  205. .LP
  206.     6.12
  207.     Reassignment after failure
  208. .LP
  209.     6.13
  210.     Retention until acknowledgment of TPDUs
  211. .LP
  212.     6.14
  213.     Resynchronization
  214. .LP
  215.     6.15
  216.     Multiplexing and demultiplexing
  217. .LP
  218.     6.16
  219.     Explicit flow control
  220. .LP
  221.     6.17
  222.     Checksum
  223. .LP
  224.     6.18
  225.     Frozen references
  226. .LP
  227.     6.19
  228.     Retransmission on timeout
  229. .LP
  230.     6.20
  231.     Resequencing
  232. .LP
  233.     6.21
  234.     Inactivity control
  235. .LP
  236.     6.22
  237.     Treatment of protocol errors
  238. .LP
  239.     6.23
  240.     Splitting and recombining
  241. .sp 1P
  242. .LP
  243. 7
  244.     \fIProtocol classes\fR 
  245. .sp 9p
  246. .RT
  247. .sp 1P
  248. .LP
  249. 8
  250.     \fISpecification for Class 0: Simple Class\fR 
  251. .sp 9p
  252. .RT
  253. .LP
  254.     8.1
  255.     Functions of Class 0
  256. .LP
  257.     8.2
  258.     Procedures for Class 0
  259. .sp 1P
  260. .LP
  261. 9
  262.     \fISpecification for Class 1: basic error recovery class\fR 
  263. .sp 9p
  264. .RT
  265. .LP
  266.     9.1
  267.     Functions of Class 1
  268. .LP
  269.     9.2
  270.     Procedures for Class 1
  271. .sp 1P
  272. .LP
  273. 10
  274.     \fISpecification for Class 2: multiplexing class\fR 
  275. .sp 9p
  276. .RT
  277. .LP
  278.     10.1
  279.     Functions of Class 2
  280. .LP
  281.     10.2
  282.     Procedures for Class 2
  283. .sp 1P
  284. .LP
  285. 11
  286.     \fISpecification for Class 3: error recovery and multiplexing class\fR 
  287. .sp 9p
  288. .RT
  289. .LP
  290.     11.1
  291.     Functions of Class 3
  292. .LP
  293.     11.2
  294.     Procedures for Class 3
  295. .sp 1P
  296. .LP
  297. 12
  298.     \fISpecification for Class 4: error detection and recovery class\fR 
  299. .sp 9p
  300. .RT
  301. .LP
  302.     12.1
  303.     Functions of Class 4
  304. .LP
  305.     12.2
  306.     Procedures for Class 4
  307. .bp
  308. .sp 1P
  309. .LP
  310. 13
  311.     \fIStructure and encoding of TPDUs\fR 
  312. .sp 9p
  313. .RT
  314. .LP
  315.     13.1
  316.     Validity
  317. .LP
  318.     13.2
  319.     Structure
  320. .LP
  321.     13.3
  322.     Connection request (CR) TPDU
  323. .LP
  324.     13.4
  325.     Connection confirm (CC) TPDU
  326. .LP
  327.     13.5
  328.     Disconnect request (DR) TPDU
  329. .LP
  330.     13.6
  331.     Disconnect confirm (DC) TPDU
  332. .LP
  333.     13.7
  334.     Data (DT) TPDU
  335. .LP
  336.     13.8
  337.     Expedited data (ED) TPDU
  338. .LP
  339.     13.9
  340.     Data acknowledgment (AK) TPDU
  341. .LP
  342.     13.10
  343.     Expedited data acknowledgment (EA)
  344. .LP
  345.     13.11
  346.     Reject (RJ) TPDU
  347. .LP
  348.     13.12
  349.     TPDU error (ER) TPDU
  350. .sp 1P
  351. .LP
  352. 14
  353.     \fIConformance\fR 
  354. .sp 9p
  355. .RT
  356. .sp 1P
  357. .LP
  358. \fIAnnex\ A\fR     \(em
  359.     State Tables
  360. .sp 9p
  361. .RT
  362. .sp 1P
  363. .LP
  364. \fIAnnex\ B\fR     \(em
  365.     Transport Protocol Identification
  366. .sp 9p
  367. .RT
  368. .sp 1P
  369. .LP
  370. \fIAppendix\ I\fR     \(em
  371.     Checksum Algorithms
  372. .sp 9p
  373. .RT
  374. .sp 1P
  375. .LP
  376. \fIApendix\ II\fR     \(em
  377.     Differences between Recommendation X.224 and
  378. ISO 8073 (1986)
  379. .sp 9p
  380. .RT
  381. .sp 2P
  382. .LP
  383. \fB0\fR     \fBIntroduction\fR 
  384. .sp 1P
  385. .RT
  386. .PP
  387. The Transport Protocol is one of a set of Recommendations produced to facilitate 
  388. the interconnection of computer systems. The set of 
  389. Recommendations covers the services and protocols required to achieve such
  390. interconnection.
  391. .PP
  392. The Transport Protocol is positioned with respect to other related
  393. Recommendations by the layers defined in the Reference Model of Open Systems
  394. Interconnection for CCITT Applications\ [1]. It is most closely
  395. related to, and lies within the field of application of the Transport
  396. Service\ [2]. It also uses and makes reference to the Network Service\ [3],
  397. whose provisions it assumes in order to accomplish the transport
  398. protocol's aims. The interrelationship of these Recommendations is depicted 
  399. in Figure\ 1/X.224. 
  400. .RT
  401. .LP
  402. .rs
  403. .sp 13P
  404. .ad r
  405. \fBFigure 1/X.224, (N), p.\fR 
  406. .sp 1P
  407. .RT
  408. .ad b
  409. .RT
  410. .LP
  411. .bp
  412. .PP
  413. This Recommendation specifies a common encoding and a number of
  414. classes of transport protocol procedures to be used with different network
  415. qualities of service.
  416. .PP
  417. It is intended that the Transport Protocol should be simple but
  418. general enough to cater for the total range of Network Service qualities
  419. possible, without restricting future extensions.
  420. .PP
  421. The protocol is structured to give rise to classes of protocol which are 
  422. designed to minimize possible incompatibilities and implementation 
  423. costs.
  424. .PP
  425. The classes are selectable with respect to the Transport and Network Services 
  426. in providing the required quality of service for the interconnection of 
  427. two session entities (note that each class provides a different set of 
  428. functions for enhancement of service qualities).
  429. .PP
  430. This protocol defines mechanisms that can be used to optimize network tariffs 
  431. and enhance the following qualities of service: 
  432. .RT
  433. .LP
  434.     a)
  435.     different throughput;
  436. .LP
  437.     b)
  438.     different error rates;
  439. .LP
  440.     c)
  441.     integrity of data requirements;
  442. .LP
  443.     d)
  444.     reliability requirements.
  445. .PP
  446. It does not require an implementation to use all of these
  447. mechanisms, nor does it define methods for measuring achieved quality of
  448. service or criteria for deciding when to release transport connections
  449. following quality of service degradation.
  450. .PP
  451. The primary aim of this Recommendation is to provide a set of rules
  452. for communication expressed in terms of the procedures to be carried out by
  453. peer entities at the time of communication. These rules for communication 
  454. are intended to provide a sound basis for development in order to serve 
  455. a variety of purposes: 
  456. .RT
  457. .LP
  458.     a)
  459.     as a guide for implementors and designers;
  460. .LP
  461.     b)
  462.     for use in the testing and procurement of equipment;
  463. .LP
  464.     c)
  465.      as part of an agreement for the admittance of systems into the open systems 
  466. environment; 
  467. .LP
  468.     d)
  469.     as a refinement of the understanding of OSI.
  470. .PP
  471. It is expected that the initial users of the Recommendation will be designers 
  472. and implementors of equipment and the Recommendation contains, in notes 
  473. or in Annexes, guidance on the implementation of the procedures defined 
  474. in the Recommendation. 
  475. .PP
  476. It should be noted that, as the number of valid protocol sequences is very 
  477. large, it is not possible with current technology to verify that an 
  478. implementation will operate the protocol defined in this Recommendation
  479. correctly under all circumstances. It is possible by means of testing to
  480. establish confidence that an implementation correctly operates the protocol 
  481. in a representative sample of circumstances. It is, however, intended that 
  482. this 
  483. Recommendation can be used in circumstances where two implementations fail 
  484. to communicate in order to determine whether one or both have failed to 
  485. operate 
  486. the protocol correctly.
  487. .PP
  488. This Recommendation contains a section on conformance of equipment
  489. claiming to implement the procedures in this Recommendation. Attention 
  490. is drawn to the fact that the Recommendation does not contain any tests 
  491. to demonstrate this conformance. 
  492. .PP
  493. The variations and options available within this Recommendation are
  494. essential to enable a Transport Service to be provided for a wide variety of
  495. applications over a variety of network qualities. Thus, a minimally conforming 
  496. implementation will not be suitable for use in all possible circumstances. 
  497. It is important therefore to qualify all references to this Recommendation 
  498. with 
  499. statements of the options provided or required or with statements of the
  500. intended purpose of provision or use.
  501. .RT
  502. .sp 2P
  503. .LP
  504. \fB1\fR     \fBScope and field of application\fR 
  505. .sp 1P
  506. .RT
  507. .PP
  508. 1.1
  509. This Recommendation specifies:
  510. .sp 9p
  511. .RT
  512. .LP
  513.     a)
  514.     five classes of procedures:
  515. .LP
  516.     1)
  517.     Class\ 0:\ Simple Class;
  518. .LP
  519.     2)
  520.     Class\ 1:\ Basic Error Recovery Class;
  521. .LP
  522.     3)
  523.     Class\ 2:\ Multiplexing Class;
  524. .bp
  525. .LP
  526.     4)
  527.     Class\ 3:\ Error Recovery and Multiplexing Class;
  528. .LP
  529.     5)
  530.     Class\ 4:\ Error Detection and Recovery Class;
  531. .LP
  532.     for the connection oriented transfer of data and control
  533. information from one transport entity to a peer transport
  534. entity;
  535. .LP
  536.     b)
  537.     the means of negotiating the class of procedures to be used
  538. by the transport entities;
  539. .LP
  540.     c)
  541.     the structure and encoding of the transport protocol data
  542. units used for the transfer of data and control
  543. information.
  544. .PP
  545. 1.2
  546. The procedures are defined in terms of:
  547. .sp 9p
  548. .RT
  549. .LP
  550.     a)
  551.      the interactions between peer transport entities through the exchange 
  552. of transport protocol data units; 
  553. .LP
  554.     b)
  555.     the interactions between a transport entity and the
  556. transport service user in the same system through the exchange of transport
  557. service primitives;
  558. .LP
  559.     c)
  560.      the interactions between a transport entity and the network service provider 
  561. through the exchange of network service primitives. 
  562. .PP
  563. These procedures are defined in the main text of the standard
  564. supplemented by state tables in Annex\ A.
  565. .PP
  566. 1.3
  567. These procedures are applicable to instances of communication between systems 
  568. which support the Transport Layer of the OSI Reference Model 
  569. and which wish to interconnect in an open systems environment.
  570. .sp 9p
  571. .RT
  572. .PP
  573. 1.4
  574. This Recommendation specifies, in \(sc\ 14, conformance for systems implementing 
  575. these procedures. It does not contain tests which can be used to demonstrate 
  576. these conformance requirements. 
  577. .sp 9p
  578. .RT
  579. .sp 2P
  580. .LP
  581. \fB2\fR     \fBReferences\fR 
  582. .sp 1P
  583. .RT
  584. .LP
  585. [1]
  586.     Recommendation X.200 \(em Reference Model of Open Systems
  587. Interconnection for CCITT Applications
  588. (see also ISO\ 7498);
  589. .LP
  590. [2]
  591.     Recommendation X.214 \(em Transport Service Definition for
  592. Open Systems Interconnection for CCITT Applications
  593. (see also ISO\ 8072;
  594. .LP
  595. [3]
  596.     Recommendation X.213 \(em Network Service Definition for
  597. Open Systems Interconnection for CCITT Applications
  598. (see also ISO\ 8348;
  599. .LP
  600. [4]
  601.     Recommendation T.70 \(em Network\(hyIndependent Basic Transport
  602. Service for Teletex;
  603. .sp 2P
  604. .LP
  605. \fB3\fR     \fBDefinitions\fR 
  606. .sp 1P
  607. .RT
  608. .PP
  609. \fINote\fR \ \(em\ The definitions contained in this section make use of
  610. abbreviations defined in \(sc\ 4.
  611. .RT
  612. .PP
  613. 3.1
  614. This Recommendation is based on the concepts developed in the Reference 
  615. Model of Open Systems Interconnection for CCITT Applications\ [1] 
  616. and makes use of the following terms defined in that Recommendation:
  617. .sp 9p
  618. .RT
  619. .LP
  620.     a)
  621.     concatenation and separation;
  622. .LP
  623.     b)
  624.     segmenting and reassembling;
  625. .LP
  626.     c)
  627.     multiplexing and demultiplexing;
  628. .LP
  629.     d)
  630.     splitting and recombining;
  631. .LP
  632.     e)
  633.     flow control.
  634. .PP
  635. 3.2
  636. For the purpose of this Recommendation, the following
  637. definitions apply:
  638. .sp 9p
  639. .RT
  640. .sp 1P
  641. .LP
  642. 3.2.1
  643.     \fBequipment\fR 
  644. .sp 9p
  645. .RT
  646. .PP
  647. Hardware or software or a combination of both; it need
  648. not be physically distinct within a computer system.
  649. .bp
  650. .RT
  651. .sp 1P
  652. .LP
  653. 3.2.2
  654.     \fBtransport service user\fR 
  655. .sp 9p
  656. .RT
  657. .PP
  658. An abstract representation of the totality of those
  659. entities within a single system that make use of the transport
  660. service.
  661. .RT
  662. .sp 1P
  663. .LP
  664. 3.2.3
  665.     \fBnetwork service provider\fR 
  666. .sp 9p
  667. .RT
  668. .PP
  669. An abstract machine which models the totality of the
  670. entities providing the network service, as viewed by a transport
  671. entity.
  672. .RT
  673. .sp 1P
  674. .LP
  675. 3.2.4
  676.     \fBlocal matter\fR 
  677. .sp 9p
  678. .RT
  679. .PP
  680. A decision made by a system concerning its behaviour in
  681. the Transport Layer that is not subject to the requirements of this
  682. protocol.
  683. .RT
  684. .sp 1P
  685. .LP
  686. 3.2.5
  687.     \fBinitiator\fR 
  688. .sp 9p
  689. .RT
  690. .PP
  691. A transport entity that initiates a CR TPDU.
  692. .RT
  693. .sp 1P
  694. .LP
  695. 3.2.6
  696.     \fBresponder\fR 
  697. .sp 9p
  698. .RT
  699. .PP
  700. A transport entity with whom an initiator wishes to establish
  701. a transport connection.
  702. .PP
  703. \fINote\fR \ \(em\ Initiator and responder are defined with respect to a
  704. single transport connection. A transport entity can be both an initiator
  705. and responder simultaneously.
  706. .RT
  707. .sp 1P
  708. .LP
  709. 3.2.7
  710.     \fBsending transport entity\fR 
  711. .sp 9p
  712. .RT
  713. .PP
  714. A transport entity that sends a given TPDU.
  715. .RT
  716. .sp 1P
  717. .LP
  718. 3.2.8
  719.     \fBreceiving transport entity\fR 
  720. .sp 9p
  721. .RT
  722. .PP
  723. A transport entity that receives a given TPDU.
  724. .RT
  725. .sp 1P
  726. .LP
  727. 3.2.9
  728.     \fBpreferred class\fR 
  729. .sp 9p
  730. .RT
  731. .PP
  732. The protocol class that the initiator indicates in a CR TPDU as
  733. its first choice for use over the transport connection.
  734. .RT
  735. .sp 1P
  736. .LP
  737. 3.2.10
  738.     \fBalternative class\fR 
  739. .sp 9p
  740. .RT
  741. .PP
  742. A protocol class that the initiator indicates in a CR TPDU as an alternative 
  743. choice for use over the transport connection. 
  744. .RT
  745. .sp 1P
  746. .LP
  747. 3.2.11
  748.     \fBproposed class\fR 
  749. .sp 9p
  750. .RT
  751. .PP
  752. A preferred class or an alternative class.
  753. .RT
  754. .sp 1P
  755. .LP
  756. 3.2.12
  757.     \fBselected class\fR 
  758. .sp 9p
  759. .RT
  760. .PP
  761. The protocol class that the responder indicates in a CC TPDU that it has 
  762. chosen for use over the transport connection. 
  763. .RT
  764. .sp 1P
  765. .LP
  766. 3.2.13
  767.     \fBproposed parameter\fR 
  768. .sp 9p
  769. .RT
  770. .PP
  771. The value for a parameter that the initiator indicates in a CR
  772. TPDU that it wishes to use over the transport connection.
  773. .RT
  774. .sp 1P
  775. .LP
  776. 3.2.14
  777.     \fBselected parameter\fR 
  778. .sp 9p
  779. .RT
  780. .PP
  781. The value for a parameter that the responder indicates in a CC
  782. TPDU that it has chosen for use over the transport connection.
  783. .bp
  784. .RT
  785. .sp 1P
  786. .LP
  787. 3.2.15
  788.     \fBerror indication\fR 
  789. .sp 9p
  790. .RT
  791. .PP
  792. An N\(hyRESET indication, or an N\(hyDISCONNECT indication with a reason 
  793. code indicating an error, that a transport entity receives from the 
  794. NS\(hyprovider.
  795. .RT
  796. .sp 1P
  797. .LP
  798. 3.2.16
  799.     \fBinvalid TPDU\fR 
  800. .sp 9p
  801. .RT
  802. .PP
  803. A TPDU which does not comply with the requirements of this
  804. Recommendation for structure and encoding.
  805. .RT
  806. .sp 1P
  807. .LP
  808. 3.2.17
  809.     \fBprotocol error\fR 
  810. .sp 9p
  811. .RT
  812. .PP
  813. A TPDU whose use does not comply with the procedures for the
  814. class.
  815. .RT
  816. .sp 1P
  817. .LP
  818. 3.2.18
  819.     \fBsequence number\fR \v'2p'
  820. .sp 9p
  821. .RT
  822. .LP
  823.     a)
  824.     The number in the TPDU\(hyNR field of a DT TPDU which
  825. indicates the order in which the DT TPDU was transmitted by a transport
  826. entity.
  827. .LP
  828.     b)
  829.      The number in the YR\(hyTU\(hyNR field of an AK or RJ TPDU which indicates 
  830. the sequence number of the next DT TPDU expected to be received by a transport 
  831. entity. 
  832. .sp 1P
  833. .LP
  834. 3.2.19
  835.     \fBtransmit window\fR 
  836. .sp 9p
  837. .RT
  838. .PP
  839. The set of consecutive sequence numbers which a transport entity has been 
  840. authorised by its peer entity to send at a given time on a given 
  841. transport connection.
  842. .RT
  843. .sp 1P
  844. .LP
  845. 3.2.20
  846.     \fBlower window edge\fR 
  847. .sp 9p
  848. .RT
  849. .PP
  850. The lowest sequence number in a transmit window.
  851. .RT
  852. .sp 1P
  853. .LP
  854. 3.2.21
  855.     \fBupper window edge\fR 
  856. .sp 9p
  857. .RT
  858. .PP
  859. The sequence number which is one greater than the highest sequence number 
  860. in the transmit window. 
  861. .RT
  862. .sp 1P
  863. .LP
  864. 3.2.22
  865.     \fBupper window edge allocated to the peer entity\fR 
  866. .sp 9p
  867. .RT
  868. .PP
  869. The value that a transport entity communicates to its peer entity to be 
  870. interpreted as its new upper window edge. 
  871. .RT
  872. .sp 1P
  873. .LP
  874. 3.2.23
  875.     \fBclosed window\fR 
  876. .sp 9p
  877. .RT
  878. .PP
  879. A transmit window which contains no sequence number.
  880. .RT
  881. .sp 1P
  882. .LP
  883. 3.2.24
  884.     \fBwindow information\fR 
  885. .sp 9p
  886. .RT
  887. .PP
  888. Information contained in a TPDU relating to the upper and the
  889. lower window edges.
  890. .RT
  891. .sp 1P
  892. .LP
  893. 3.2.25
  894.     \fBfrozen reference\fR 
  895. .sp 9p
  896. .RT
  897. .PP
  898. A reference which is not available for assignment to a connection because 
  899. of the requirements of \(sc\ 6.18. 
  900. .RT
  901. .sp 1P
  902. .LP
  903. 3.2.26
  904.     \fBunassigned reference\fR 
  905. .sp 9p
  906. .RT
  907. .PP
  908. A reference that is neither currently in use for identifying a
  909. transport connection nor in a frozen state.
  910. .RT
  911. .sp 1P
  912. .LP
  913. 3.2.27
  914.     \fBtransparent (data)\fR 
  915. .sp 9p
  916. .RT
  917. .PP
  918. TS\(hyuser data which is transferred intact between transport
  919. entities and which is unavailable for use by the transport
  920. entities.
  921. .bp
  922. .RT
  923. .sp 1P
  924. .LP
  925. 3.2.28
  926.     \fBowner (of a network connection)\fR 
  927. .sp 9p
  928. .RT
  929. .PP
  930. The transport entity that issued the N\(hyCONNECT request leading
  931. to the creation of that network connection.
  932. .RT
  933. .sp 1P
  934. .LP
  935. 3.2.29
  936.     \fBretained TPDU\fR 
  937. .sp 9p
  938. .RT
  939. .PP
  940. A TPDU which is subject to the retransmission procedure or
  941. retention until acknowledgment procedure and is available for possible
  942. retransmission.
  943. .RT
  944. .sp 2P
  945. .LP
  946. \fB4\fR     \fBSymbols and abbreviations\fR 
  947. .sp 1P
  948. .RT
  949. .sp 1P
  950. .LP
  951. 4.1
  952.     \fIData units\fR \v'2p'
  953. .sp 9p
  954. .RT
  955. .LP
  956.     TPDU
  957.     Transport Protocol Data Unit
  958. .LP
  959.     TSDU
  960.     Transport Service Data Unit
  961. .LP
  962.     NSDU
  963.     Network Service Data Unit
  964. .sp 1P
  965. .LP
  966. 4.2
  967.     \fITypes of transport protocol data unit\fR \v'2p'
  968. .sp 9p
  969. .RT
  970. .LP
  971.     CR\ TPDU
  972.     Connection Request TPDU
  973. .LP
  974.     CC\ TPDU
  975.     Connection Confirm TPDU
  976. .LP
  977.     DR\ TPDU
  978.     Disconnect Request TPDU
  979. .LP
  980.     DC\ TPDU
  981.     Disconnect Confirm TPDU
  982. .LP
  983.     DT\ TPDU
  984.     Data TPDU
  985. .LP
  986.     ED\ TPDU
  987.     Expedited Data TPDU
  988. .LP
  989.     AK\ TPDU
  990.     Data Acknowledge TPDU
  991. .LP
  992.     EA\ TPDU
  993.     Expedited Acknowledge TPDU
  994. .LP
  995.     RJ\ TPDU
  996.     Reject TPDU
  997. .LP
  998.     ER\ TPDU
  999.     Error TPDU
  1000. .sp 1P
  1001. .LP
  1002. 4.3
  1003.     \fITPDU fields\fR \v'2p'
  1004. .sp 9p
  1005. .RT
  1006. .LP
  1007.     LI
  1008.     Length Indicator (field)
  1009. .LP
  1010.     CDT
  1011.     Credit (field)
  1012. .LP
  1013.     TSAP\(hyID
  1014.     Transport Service Access Point Identifier
  1015. (field)
  1016. .LP
  1017.     DST\(hyREF
  1018.     Destination Reference (field)
  1019. .LP
  1020.     SRC\(hyREF
  1021.     Source Reference (field)
  1022. .LP
  1023.     EOT
  1024.     End of TSDU mark
  1025. .LP
  1026.     TPDU\(hyNR
  1027.     DT TPDU number (field)
  1028. .LP
  1029.     ED\(hyTPDU\(hyNR
  1030.     ED TPDU number (field)
  1031. .LP
  1032.     YR\(hyTU\(hyNR
  1033.     Sequence number response (field)
  1034. .LP
  1035.     YR\(hyEDTU\(hyNR
  1036.     ED TPDU number response (field)
  1037. .sp 1P
  1038. .LP
  1039. 4.4
  1040.     \fITimes and associated variables\fR \v'2p'
  1041. .sp 9p
  1042. .RT
  1043. .LP
  1044.     T1
  1045.     Local retransmission time
  1046. .LP
  1047.     N
  1048.     The maximum number of retransmissions
  1049. .LP
  1050.     L
  1051.     Time bound on reference and sequence numbers
  1052. .bp
  1053. .LP
  1054.     I
  1055.     Inactivity time
  1056. .LP
  1057.     W
  1058.     Window time
  1059. .LP
  1060.     TTR
  1061.     Time to try reassignment/resynchronization
  1062. .LP
  1063.     TWR
  1064.     Time to wait for reassignment/resynchronization
  1065. .LP
  1066.     TS1
  1067.     Supervisory timer 1
  1068. .LP
  1069.     TS2
  1070.     Supervisory timer 2
  1071. .LP
  1072.     M\dL\\dR\u    NSDU lifetime local\(hyto\(hyremote
  1073. .LP
  1074.     M\dR\\dL\u    NSDU lifetime remote\(hyto\(hylocal
  1075. .LP
  1076.     E\dL\\dR\u    Expected maximum transit delay
  1077. local\(hyto\(hyremote
  1078. .LP
  1079.     E\dR\\dL\u    Expected maximum transit delay
  1080. remote\(hyto\(hylocal
  1081. .LP
  1082.     R
  1083.     Persistence time
  1084. .LP
  1085.     A\dL\u    Local acknowledge time
  1086. .LP
  1087.     A\dR\u    Remote acknowledge time
  1088. .sp 1P
  1089. .LP
  1090. 4.5
  1091.     \fIMiscellaneous\fR \v'2p'
  1092. .sp 9p
  1093. .RT
  1094. .LP
  1095.     TS\(hyuser
  1096.     Transport Service user
  1097. .LP
  1098.     TSAP
  1099.     Transport Service Access Point
  1100. .LP
  1101.     NS\(hyprovider
  1102.     Network Service provider
  1103. .LP
  1104.     NSAP
  1105.     Network Service Access Point
  1106. .LP
  1107.     QOS
  1108.     Quality of service
  1109. .sp 2P
  1110. .LP
  1111. \fB5\fR     \fBOverview of the\fR 
  1112. \fBtransport protocol\fR 
  1113. .sp 1P
  1114. .RT
  1115. .PP
  1116. \fINote\fR \ \(em\ This overview is not exhaustive and has been provided 
  1117. for guidance to the reader of this Recommendation. 
  1118. .RT
  1119. .sp 1P
  1120. .LP
  1121. 5.1
  1122.     \fIService provided by the\fR 
  1123. \fItransport layer\fR 
  1124. .sp 9p
  1125. .RT
  1126. .PP
  1127. The protocol specified in this Recommendation supports the
  1128. transport service defined in\ [2].
  1129. .PP
  1130. Information is transferred to and from the TS\(hyuser in the transport
  1131. service primitives listed in Table\ 1/X.224.
  1132. .RT
  1133. .sp 1P
  1134. .LP
  1135. 5.2
  1136.     \fIService assumed from the\fR 
  1137. \fInetwork layer\fR 
  1138. .sp 9p
  1139. .RT
  1140. .PP
  1141. The protocol specified in this Recommendation assumes the use of
  1142. the network services defined in\ [3].
  1143. .PP
  1144. Information is transferred to and from the NS\(hyprovider in the network 
  1145. service primitives listed in Table\ 2/X.224. 
  1146. .RT
  1147. .sp 2P
  1148. .LP
  1149. 5.3
  1150.     \fIFunctions of the\fR 
  1151. \fItransport layer\fR 
  1152. .sp 1P
  1153. .RT
  1154. .sp 1P
  1155. .LP
  1156. 5.3.1
  1157.     \fIOverview of functions\fR 
  1158. .sp 9p
  1159. .RT
  1160. .PP
  1161. The functions in the transport layer are those necessary to bridge the 
  1162. gap between the services available from the network layer and those to 
  1163. be offered to the TS\(hyusers. 
  1164. .PP
  1165. The functions in the transport layer are concerned with the
  1166. enhancement of quality of service, including aspects of cost optimization.
  1167. .PP
  1168. The functions are grouped below into those used at all times during a transport 
  1169. connection and those concerned with connection establishment, data 
  1170. transfer and release.
  1171. .bp
  1172. .PP
  1173. \fINote\fR \ \(em\ This Recommendation does not include the following functions 
  1174. which are under consideration for inclusion in future editions of this 
  1175. Recommendation:
  1176. .RT
  1177. .LP
  1178.     a)
  1179.     encryption;
  1180. .LP
  1181.     b)
  1182.     accounting mechanisms;
  1183. .LP
  1184.     c)
  1185.     status exchanges and monitoring of QOS;
  1186. .LP
  1187.     d)
  1188.     blocking;
  1189. .LP
  1190.     e)
  1191.     temporary release of network connections;
  1192. .LP
  1193.     f
  1194. )
  1195.     alternative checksum algorithm.
  1196. .LP
  1197. .ce
  1198. \fBH.T. [T1.224]\fR 
  1199. .ce
  1200. TABLE 1/X.224
  1201. .ce
  1202. \fBTransport service primitives\fR 
  1203. .ps 9
  1204. .vs 11
  1205. .nr VS 11
  1206. .nr PS 9
  1207. .TS
  1208. center box;
  1209. lw(84p) | lw(144p) .
  1210.     
  1211. .TE
  1212. .nr PS 9
  1213. .RT
  1214. .ad r
  1215. \fBTableau 1/X.224 [T1.224], p. 2\fR 
  1216. .sp 1P
  1217. .RT
  1218. .ad b
  1219. .RT
  1220. .sp 1P
  1221. .LP
  1222. 5.3.1.1
  1223.     \fIFunctions used at all times\fR 
  1224. .sp 9p
  1225. .RT
  1226. .PP
  1227. The following functions, depending on the selected class and
  1228. options, are used at all times during a transport connection:
  1229. .RT
  1230. .LP
  1231.     a)
  1232.     \fItransmission of TPDUs\fR \| (see \(sc\(sc\ 6.2 and 6.9);
  1233. .LP
  1234.     b)
  1235.      \fImultiplexing and demultiplexing\fR \| (see \(sc\ 6.15), a function 
  1236. used to share a single network connection between two or more transport 
  1237. connections;
  1238. .LP
  1239.     c)
  1240.      \fIerror detection\fR \| (see \(sc\(sc\ 6.10, 6.13 and 6.17), a function 
  1241. used to detect the loss, corruption, duplication, misordering or misdelivery 
  1242. of TPDUs;
  1243. .LP
  1244.     d)
  1245.     \fIerror recovery\fR \| (see \(sc\(sc\ 6.12, 6.14, 6.18, 6.19, 6.20,
  1246. 6.21 and 6.22), a function used to recover from detected and signalled
  1247. errors.
  1248. .bp
  1249. .ce
  1250. \fBH.T. [T2.224]\fR 
  1251. .ce
  1252. TABLE\ 2/X.224
  1253. .ce
  1254. \fBNetwork service primitives\fR 
  1255. .ps 9
  1256. .vs 11
  1257. .nr VS 11
  1258. .nr PS 9
  1259. .TS
  1260. center box;
  1261. lw(84p) | lw(18p) | lw(102p) | lw(24p) .
  1262.             
  1263. .T&
  1264. lw(84p) | lw(18p) | lw(102p) | lw(24p) .
  1265.     T{
  1266. Receipt confirmation selection,
  1267. Y
  1268. T}        
  1269. .T&
  1270. lw(84p) | lw(18p) | lw(102p) | lw(24p) .
  1271.     T{
  1272. Expedited data selection,
  1273. Y
  1274. .
  1275. .
  1276. QOS parameter set,
  1277. X
  1278. .
  1279. .
  1280. NS user data (3).
  1281. Z
  1282. N\(hyCONNECT response
  1283. X
  1284. Responding address.
  1285. X
  1286. N\(hyCONNECT confirmation
  1287. X
  1288. Receipt confirmation selection,
  1289. Y
  1290. .
  1291. .
  1292. Expedited data selection,
  1293. Y
  1294. .
  1295. .
  1296. QOS parameter set,
  1297. X
  1298. .
  1299. .
  1300. NS user data (3).
  1301. Z
  1302. N\(hyDATA request
  1303. X
  1304. NX\(hyuser data.
  1305. X
  1306. N\(hyDATA indication
  1307. X
  1308. Confirmation request.
  1309. Y
  1310. N\(hyDATA ACKNOWLEDGE request
  1311. Y
  1312. N\(hyDATA ACKNOWLEDGE indication
  1313. Y
  1314. N\(hyEXPEDITED DATA request
  1315. Y
  1316. NS user data.
  1317. Y
  1318. N\(hyEXPEDITED DATA indication
  1319. Y
  1320. N\(hyRESET request
  1321. X
  1322. Reason.
  1323. Z
  1324. N\(hyRESET indication
  1325. X
  1326. Originator,
  1327. Reason.
  1328. Z
  1329. Z
  1330. N\(hyRESET response
  1331. X
  1332. N\(hyRESET confirmation
  1333. X
  1334. N\(hyDISCONNECT request
  1335. X
  1336. Reason,
  1337. NS user data,
  1338. Responding address
  1339. Z
  1340. Z
  1341. Z
  1342. N\(hyDISCONNECT indication
  1343. X
  1344. Originator,
  1345. Reason,
  1346. NS user data
  1347. Responding address.
  1348. Z
  1349. Z
  1350. Z
  1351. Z
  1352. X:
  1353. The Transport Protocol assumes that this feature is provided by all
  1354. network service providers.
  1355. .line
  1356. Y:
  1357. The Transport Protocol assumes that this feature is provided by some
  1358. network service providers and a mechanism is provided to optionally use the
  1359. feature.
  1360. .line
  1361. Z:
  1362. The Transport Protocol does not use this parameter.
  1363. .parag
  1364. \fINote\ 1\fR
  1365. \ \(em\ The parameters listed in this table are those in the network service definition (Reference\ 3).
  1366. .parag
  1367. \fINote\ 2\fR
  1368. \ \(em\ The way the parameters are exchanged between the transport entity
  1369. and the NS\(hyprovider is a local matter.
  1370. .parag
  1371. \fINote\ 3\fR
  1372. \ \(em\ Although not used in the transport protocol \fIper se\fR
  1373. , this parameter may be used for transport protocol identification, as specified in
  1374. Annex\ B.
  1375. .parag
  1376. T}        
  1377. .TE
  1378. .nr PS 9
  1379. .RT
  1380. .ad r
  1381. \fBTableau 2/X.224 [T2.224], p. 3\fR 
  1382. .sp 1P
  1383. .RT
  1384. .ad b
  1385. .RT
  1386. .LP
  1387. .bp
  1388. .sp 1P
  1389. .LP
  1390. 5.3.1.2
  1391.     \fIConnection establishment\fR 
  1392. .sp 9p
  1393. .RT
  1394. .PP
  1395. The purpose of connection establishment is to establish a transport connection 
  1396. between two TS\(hyusers. The following functions of the transport layer 
  1397. during this phase match the TS\(hyusers' requested quality of service with 
  1398. the 
  1399. services offered by the network layer:
  1400. .RT
  1401. .LP
  1402.     a)
  1403.     select network service which best matches the
  1404. requirement of the TS\(hyuser taking into account charges for
  1405. various services (see \(sc\ 6.5);
  1406. .LP
  1407.     b)
  1408.     decide whether to multiplex multiple transport connections
  1409. onto a single network connection (see \(sc\ 6.5);
  1410. .LP
  1411.     c)
  1412.     establish the optimum TPDU size (see \(sc\ 6.5);
  1413. .LP
  1414.     d)
  1415.     select the functions that will be operational upon entering
  1416. the data transfer phase (see \(sc\ 6.5);
  1417. .LP
  1418.     e)
  1419.     map transport addresses onto network addresses;
  1420. .LP
  1421.     f
  1422. )
  1423.     provide a means to distinguish between two different
  1424. transport connections (see \(sc\ 6.5);
  1425. .LP
  1426.     g)
  1427.     transport of TS\(hyuser data (see \(sc\ 6.5).
  1428. .sp 1P
  1429. .LP
  1430. 5.3.1.3
  1431.     \fIData transfer\fR 
  1432. .sp 9p
  1433. .RT
  1434. .PP
  1435. The purpose of data transfer is to permit duplex transmission of
  1436. TSDUs between the two TS\(hyusers connected by the transport connection. This
  1437. purpose is achieved by means of two\(hyway simultaneous communication and 
  1438. by the following functions, some of which are used or not used in accordance 
  1439. with the result of the selection performed in connection establishment. 
  1440. .RT
  1441. .LP
  1442.     a)
  1443.     \fIconcatenation and separation\fR \| (see \(sc\ 6.4), a function used
  1444. to collect several TPDUs into a single NSDU at the sending
  1445. transport entity and to separate the TPDUs at the receiving
  1446. transport entity;
  1447. .LP
  1448.     b)
  1449.     \fIsegmenting and reassembling\fR \| (see \(sc\ 6.3), a function used
  1450. to segment a single TSDU into multiple TPDUs at the sending
  1451. transport entity and to reassemble them into their original
  1452. format at the receiving transport entity;
  1453. .LP
  1454.     c)
  1455.     \fIsplitting and recombining\fR \| (see \(sc\ 6.23), a function
  1456. allowing the simultaneous use of two or more network connections
  1457. to support the same transport connection;
  1458. .LP
  1459.     d)
  1460.     \fIflow control\fR \| (see \(sc\ 6.16), a function used to regulate
  1461. the flow of TPDUs between two transport entities on one
  1462. transport connection;
  1463. .LP
  1464.     e)
  1465.     \fItransport connection identification\fR , a means to uniquely
  1466. identify a transport connection between the pair of transport
  1467. entities supporting the connection during the lifetime of the
  1468. transport connection;
  1469. .LP
  1470.     f
  1471. )
  1472.     \fIexpedited data\fR \| (see \(sc\ 6.11), a function used to
  1473. bypass the flow control of normal data TPDU. Expedited data TPDU
  1474. flow is controlled by separate flow control;
  1475. .LP
  1476.     g)
  1477.     \fITSDU delimiting\fR \| (see \(sc\ 6.3), a function used to determine
  1478. the beginning and ending of a TSDU.
  1479. .sp 1P
  1480. .LP
  1481. 5.3.1.4
  1482.     \fIRelease\fR 
  1483. .sp 9p
  1484. .RT
  1485. .PP
  1486. The purpose of release (see \(sc\(sc\ 6.7 and 6.8) is to provide
  1487. disconnection of the transport connection, regardless of the current
  1488. activity.
  1489. .RT
  1490. .sp 2P
  1491. .LP
  1492. 5.4
  1493.     \fIClasses and options\fR 
  1494. .sp 1P
  1495. .RT
  1496. .sp 1P
  1497. .LP
  1498. 5.4.1
  1499.     \fIGeneral\fR 
  1500. .sp 9p
  1501. .RT
  1502. .PP
  1503. The functions of the transport layer have been organized into
  1504. classes and options.
  1505. .PP
  1506. A class defines a set of functions. Options define those functions
  1507. within a class which may or may not be used.
  1508. .PP
  1509. This Recommendation defines five classes of protocol:
  1510. .RT
  1511. .LP
  1512.     a)
  1513.     Class\ 0:\ Simple Class;
  1514. .LP
  1515.     b)
  1516.     Class\ 1:\ Basic Error Recovery Class;
  1517. .bp
  1518. .LP
  1519.     c)
  1520.     Class\ 2:\ Multiplexing Class;
  1521. .LP
  1522.     d)
  1523.     Class\ 3:\ Error Recovery and Multiplexing Class;
  1524. .LP
  1525.     e)
  1526.     Class\ 4:\ Error Detection and Recovery Class.
  1527. .PP
  1528. \fINote\ 1\fR \ \(em\ Transport connections of Classes 2, 3 and 4 may be
  1529. multiplexed together onto the same network connection.
  1530. .PP
  1531. \fINote\ 2\fR \ \(em\ Classes 0 to 3 do not specify mechanisms to detect
  1532. unsignalled network transmission failures.
  1533. .RT
  1534. .sp 1P
  1535. .LP
  1536. 5.4.2
  1537.     \fINegotiation\fR 
  1538. .sp 9p
  1539. .RT
  1540. .PP
  1541. The use of classes and options is negotiated during connection
  1542. establishment. The choice made by the transport entities will depend
  1543. on:
  1544. .RT
  1545. .LP
  1546.     a)
  1547.     the TS\(hyusers' requirements expressed via T\(hyCONNECT service
  1548. primitives;
  1549. .LP
  1550.     b)
  1551.     the quality of the available network services;
  1552. .LP
  1553.     c)
  1554.     the user required service versus cost ratio acceptable for
  1555. the TS\(hyuser.
  1556. .sp 1P
  1557. .LP
  1558. 5.4.3
  1559.     \fIChoice of network connection\fR 
  1560. .sp 9p
  1561. .RT
  1562. .PP
  1563. The following list classifies network services in terms of quality with 
  1564. respect to error behaviour in relation to user requirements; its main 
  1565. purpose is to provide a basis for the decision regarding which class of
  1566. transport connection should be used in conjunction with a given network
  1567. connection.
  1568. .RT
  1569. .LP
  1570.     a)
  1571.     \fIType\ A\fR \ \(em\ Network connection with acceptable residual error
  1572. rate (for example not signalled by disconnect or reset) and
  1573. acceptable rate of signalled errors.
  1574. .LP
  1575.     b)
  1576.     \fIType\ B\fR \ \(em\ Network connections with acceptable residual
  1577. error rate (for example not signalled by disconnect or reset)
  1578. but unacceptable rate of signalled errors.
  1579. .LP
  1580.     c)
  1581.     \fIType\ C\fR \ \(em\ Network connections with unacceptable residual
  1582. error rate.
  1583. .PP
  1584. It is assumed that each transport entity is aware of the quality of service 
  1585. provided by particular Network connection. 
  1586. .sp 1P
  1587. .LP
  1588. 5.4.4
  1589.     \fICharacteristics of\fR 
  1590. \fIClass 0\fR 
  1591. .sp 9p
  1592. .RT
  1593. .PP
  1594. Class 0 provides the simplest type of transport connection and is fully 
  1595. compatible with Recommendation\ T.70\ [4]. 
  1596. .PP
  1597. Class 0 has been designed to be used with type\ A network
  1598. connections.
  1599. .RT
  1600. .sp 1P
  1601. .LP
  1602. 5.4.5
  1603.     \fICharacteristics of\fR 
  1604. \fIClass 1\fR 
  1605. .sp 9p
  1606. .RT
  1607. .PP
  1608. Class 1 provides a basic transport connection with minimal
  1609. overheads.
  1610. .PP
  1611. The main purpose of the class is to recover from network disconnect or reset.
  1612. .PP
  1613. Selection of this class is usually based on reliability criteria.
  1614. Class\ 1 has been designed to be used with type\ B network
  1615. connections.
  1616. .RT
  1617. .sp 2P
  1618. .LP
  1619. 5.4.6
  1620.     \fICharacteristics of\fR 
  1621. \fIClass 2\fR 
  1622. .sp 1P
  1623. .RT
  1624. .sp 1P
  1625. .LP
  1626. 5.4.6.1
  1627.     \fIGeneral\fR 
  1628. .sp 9p
  1629. .RT
  1630. .PP
  1631. Class 2 provides a way to multiplex several transport connections onto 
  1632. a single network connection. This class has been designed to be used with 
  1633. type\ A network connections. 
  1634. .RT
  1635. .sp 1P
  1636. .LP
  1637. 5.4.6.2
  1638.     \fIUse of explicit flow control\fR 
  1639. .sp 9p
  1640. .RT
  1641. .PP
  1642. The objective is to provide flow control to help avoid congestion at transport\(hyconnection\(hyend\(hypoints 
  1643. and on the network connection. Typical use is when traffic is heavy and 
  1644. continuous, or when there is intensive 
  1645. multiplexing. Use of flow control can optimize response times and resource
  1646. utilization.
  1647. .bp
  1648. .RT
  1649. .sp 1P
  1650. .LP
  1651. 5.4.6.3
  1652.     \fINon\(hyuse of explicit flow control\fR 
  1653. .sp 9p
  1654. .RT
  1655. .PP
  1656. The objective is to provide a basic transport connection with
  1657. minimal overheads suitable when explicit disconnection of the transport
  1658. connection is desirable. The option would typically be used for unsophisticated 
  1659. terminals, and when no multiplexing onto network connections is required. 
  1660. Expedited data is never available.
  1661. .RT
  1662. .sp 1P
  1663. .LP
  1664. 5.4.7
  1665.     \fICharacteristics of\fR 
  1666. \fIClass 3\fR 
  1667. .sp 9p
  1668. .RT
  1669. .PP
  1670. Class 3 provides the characteristics of Class 2 plus the ability to recover 
  1671. from network disconnect or reset. Selection of this class is usually 
  1672. based upon reliability criteria. Class\ 3 has been designed to be used with
  1673. type\ B network connections.
  1674. .RT
  1675. .sp 1P
  1676. .LP
  1677. 5.4.8
  1678.     \fICharacteristics of\fR 
  1679. \fIClass 4\fR 
  1680. .sp 9p
  1681. .RT
  1682. .PP
  1683. Class 4 provides the characteristics of Class 3, plus the
  1684. capability to detect and recover from errors which occur as a result of 
  1685. the low grade of service available from the NS\(hyprovider. The kinds of 
  1686. errors to be 
  1687. detected include: TPDU loss, TPDU delivery out of sequence, TPDU duplication
  1688. and TPDU corruption. These errors may affect control TPDUs as well as data
  1689. TPDUs.
  1690. .PP
  1691. This class also provides for increased throughput capability and
  1692. additional resilience against network failure.
  1693. .PP
  1694. Class 4 has been designed to be used with type C network
  1695. connections.
  1696. .RT
  1697. .sp 1P
  1698. .LP
  1699. 5.5
  1700.     \fIModel of the transport layer\fR 
  1701. .sp 9p
  1702. .RT
  1703. .PP
  1704. A transport entity communicates with its TS\(hyusers through one or
  1705. more TSAPs by means of the service primitives as defined by the transport
  1706. service definition (Reference\ 2). Service primitives will cause or be the
  1707. result of transport protocol data unit exchanges between the peer transport
  1708. entities supporting a transport connection. These protocol exchanges are
  1709. effected using the services of the network layer as defined by the network
  1710. service definition\ [3] through one or more NSAPs.
  1711. .PP
  1712. Transport connection endpoints are identified in end systems by an
  1713. internal, implementation\(hydependent mechanism so that the TS\(hyuser and the
  1714. transport entity can refer to each transport connection (see
  1715. Figure\ 2/X.224).
  1716. .RT
  1717. .LP
  1718. .rs
  1719. .sp 20P
  1720. .ad r
  1721. \fBFigure 2/X.224, (N), p.\fR 
  1722. .sp 1P
  1723. .RT
  1724. .ad b
  1725. .RT
  1726. .LP
  1727. .bp
  1728. .sp 2P
  1729. .LP
  1730. \fB6\fR     \fBElements of procedure\fR 
  1731. .sp 1P
  1732. .RT
  1733. .PP
  1734. This section contains elements of procedure which are used in the specification 
  1735. of protocol classes in \(sc\(sc\ 7 to\ 12. These elements are not 
  1736. meaningful on their own.
  1737. .PP
  1738. The procedures define the transfer of TPDUs whose structure and coding 
  1739. is specified in \(sc\ 13. Transport entities shall accept and respond to 
  1740. any TPDU received in a valid NSDU and may issue TPDUs initiating specific 
  1741. elements of 
  1742. procedure specified in this section.
  1743. .PP
  1744. \fINote\fR \ \(em\ Where network service primitives or TPDUs and parameters 
  1745. used are not significant for a particular element of procedure, they have 
  1746. not been included in the specification. 
  1747. .RT
  1748. .sp 2P
  1749. .LP
  1750. 6.1
  1751.     \fIAssignment to network connection\fR 
  1752. .sp 1P
  1753. .RT
  1754. .sp 1P
  1755. .LP
  1756. 6.1.1
  1757.     \fIPurpose\fR 
  1758. .sp 9p
  1759. .RT
  1760. .PP
  1761. The procedure is used in all classes to assign transport
  1762. connections to network connections.
  1763. .RT
  1764. .sp 1P
  1765. .LP
  1766. 6.1.2
  1767.     \fINetwork service primitives\fR 
  1768. .sp 9p
  1769. .RT
  1770. .PP
  1771. The procedure makes use of the following network service
  1772. primitives:
  1773. .RT
  1774. .LP
  1775.     a)
  1776.     N\(hyCONNECT;
  1777. .LP
  1778.     b)
  1779.     N\(hyDISCONNECT.
  1780. .sp 1P
  1781. .LP
  1782. 6.1.3
  1783.     \fIProcedure\fR 
  1784. .sp 9p
  1785. .RT
  1786. .PP
  1787. Each transport connection shall be assigned to a network
  1788. connection. The initiator may assign the transport connection to an existing
  1789. network connection of which it is the owner or to a new network connection 
  1790. (see Note\ 1) which it creates for this purpose. 
  1791. .PP
  1792. The initiator shall not assign or reassign the transport connection
  1793. to an existing network connection if the protocol class(es) proposed or the
  1794. class in use for the transport connection are incompatible with the current
  1795. usage of the network connection with respect to multiplexing (see Note\ 2).
  1796. .PP
  1797. During the resynchronization (see \(sc\ 6.14) and reassignment after
  1798. failure (see \(sc\ 6.12) procedures, a transport entity may reassign a 
  1799. transport 
  1800. connection to another network connection joining the same NSAPs, provided 
  1801. that it is the owner of the network connection and that the transport connection 
  1802. is assigned to only one network connection at any given time. 
  1803. .PP
  1804. During the splitting procedure (see \(sc\ 6.23), a transport entity may
  1805. assign a transport connection to any additional network connection joining 
  1806. the same NSAPs, provided that it is the owner of the network connection 
  1807. and that 
  1808. multiplexing is possible on the network connection.
  1809. .PP
  1810. The responder becomes aware of the assignment when it
  1811. receives:
  1812. .RT
  1813. .LP
  1814.     a)
  1815.     a CR TPDU during the connection establishment procedure
  1816. (see \(sc\ 6.5); or
  1817. .LP
  1818.     b)
  1819.     an RJ TPDU or a retransmitted CR or DR TPDU during the
  1820. resynchronization (see \(sc\ 6.14) and reassignment after
  1821. failure (see \(sc\ 6.12) procedures; or
  1822. .LP
  1823.     c)
  1824.     any TPDU when splitting (see \(sc\ 6.23) is
  1825. used.
  1826. .PP
  1827. \fINote\ 1\fR \ \(em\ When a new network connection is created, the quality 
  1828. of service requested is a local matter, although it will normally be related 
  1829. to the requirements of transport connection(s) expected to be assigned 
  1830. to it. 
  1831. .PP
  1832. \fINote\ 2\fR \ \(em\ An existing network connection may also not be suitable 
  1833. if, for example, the quality of service requested for the transport connection 
  1834. cannot be attained by using or enhancing the network connection.
  1835. .PP
  1836. \fINote\ 3\fR \ \(em\ A network connection with no transport connection(s)
  1837. assigned to it, may be available after initial establishment or because
  1838. all of the transport connections previously assigned to it have been released. 
  1839. It is suggested that only the owner of such a network connection should 
  1840. release it. Furthermore, it is suggested that it not be released immediately 
  1841. after the transmission of the final TPDU of a transport connection \(em\ 
  1842. either a DR\ TPDU in response to a CR\ TPDU or a DC\ TPDU in response to 
  1843. a DR\ TPDU. An appropriate 
  1844. delay will allow the TPDU concerned to reach the other transport entity,
  1845. allowing the freeing of any resources associated with the transport connection 
  1846. concerned. 
  1847. .bp
  1848. .PP
  1849. \fINote\ 4\fR \ \(em\ After the failure of a network connection, transport
  1850. connections which were previously multiplexed together may be assigned to
  1851. different network connections, and vice versa.
  1852. .PP
  1853. \fINote\ 5\fR \ \(em\ The transport protocol identification procedures
  1854. specified in Annex\ B may need to be considered in conjunction with this
  1855. procedure.
  1856. .RT
  1857. .sp 2P
  1858. .LP
  1859. 6.2
  1860.     \fITransport protocol data unit (TPDU) transfer\fR 
  1861. .sp 1P
  1862. .RT
  1863. .sp 1P
  1864. .LP
  1865. 6.2.1
  1866.     \fIPurpose\fR 
  1867. .sp 9p
  1868. .RT
  1869. .PP
  1870. The TPDU transfer procedure is used in all classes to convey
  1871. transport protocol data units in user data fields of network service
  1872. primitives.
  1873. .RT
  1874. .sp 1P
  1875. .LP
  1876. 6.2.2
  1877.     \fINetwork service primitives\fR 
  1878. .sp 9p
  1879. .RT
  1880. .PP
  1881. This procedure uses the following network service
  1882. primitives:
  1883. .RT
  1884. .LP
  1885.     a)
  1886.     N\(hyDATA;
  1887. .LP
  1888.     b)
  1889.     N\(hyEXPEDITED DATA.
  1890. .sp 1P
  1891. .LP
  1892. 6.2.3
  1893.     \fIProcedure\fR 
  1894. .sp 9p
  1895. .RT
  1896. .PP
  1897. The transport protocol data units (TPDUs) defined for the protocol are 
  1898. listed in \(sc\ 4.2. 
  1899. .PP
  1900. When the network expedited variant has been selected for Class\ 1, the 
  1901. transport entities shall transmit and receive ED and EA\ TPDUs as NS\(hyuser 
  1902. data parameters of N\(hyEXPEDITED DATA primitives. 
  1903. .PP
  1904. In all other cases, transport entities shall transmit and receive
  1905. TPDUs as NS\(hyuser data parameters of N\(hyDATA primitives.
  1906. .PP
  1907. When a TPDU is put into an NS\(hyuser data parameter, the significance
  1908. of the bits within an octet and the order of octets within a TPDU shall be
  1909. as defined in \(sc\ 13.2.
  1910. .PP
  1911. \fINote\ 1\fR \ \(em\ TPDUs may be concatenated (see \(sc\ 6.4).
  1912. .PP
  1913. \fINote\ 2\fR \ \(em\ The transport protocol identification procedures
  1914. specified in Annex\ B may need to be considered in conjunction with this
  1915. procedure.
  1916. .RT
  1917. .sp 2P
  1918. .LP
  1919. 6.3
  1920.     \fISegmenting and reassembling\fR 
  1921. .sp 1P
  1922. .RT
  1923. .sp 1P
  1924. .LP
  1925. 6.3.1
  1926.     \fIPurpose\fR 
  1927. .sp 9p
  1928. .RT
  1929. .PP
  1930. The segmenting and reassembling procedure is used in all classes
  1931. to map TSDUs onto TPDUs.
  1932. .RT
  1933. .sp 1P
  1934. .LP
  1935. 6.3.2
  1936.     \fITPDUs and parameters used\fR 
  1937. .sp 9p
  1938. .RT
  1939. .PP
  1940. The procedure makes use of the following TPDU and
  1941. parameter:
  1942. .RT
  1943. .LP
  1944.     DT TPDU:
  1945. .LP
  1946.     \(em
  1947.     End of TSDU.
  1948. .sp 1P
  1949. .LP
  1950. 6.3.3
  1951.     \fIProcedure\fR 
  1952. .sp 9p
  1953. .RT
  1954. .PP
  1955. A transport entity shall map a TSDU on to an ordered sequence of
  1956. one or more DT\ TPDUs. This sequence shall not be interrupted by other 
  1957. DT\ TPDUs on the same transport connection. 
  1958. .PP
  1959. All DT TPDUs except the last DT TPDU in a sequence greater than one
  1960. shall have a length of data greater than\ zero.
  1961. .PP
  1962. \fINote\ 1\fR \ \(em\ The EOT of a DT TPDU indicates whether or not there are
  1963. subsequent DT TPDUs in the sequence.
  1964. .PP
  1965. \fINote\ 2\fR \ \(em\ There is no requirement that the DT TPDUs shall be 
  1966. of the maximum length selected during connection establishment. 
  1967. .bp
  1968. .RT
  1969. .sp 2P
  1970. .LP
  1971. 6.4
  1972.     \fIConcatenation and separation\fR 
  1973. .sp 1P
  1974. .RT
  1975. .sp 1P
  1976. .LP
  1977. 6.4.1
  1978.     \fIPurpose\fR 
  1979. .sp 9p
  1980. .RT
  1981. .PP
  1982. The procedure for concatenation and separation is used in
  1983. Classes\ 1, 2, 3 and\ 4 to convey multiple TPDUs in one\ NSDU.
  1984. .RT
  1985. .sp 1P
  1986. .LP
  1987. 6.4.2
  1988.     \fIProcedure\fR 
  1989. .sp 9p
  1990. .RT
  1991. .PP
  1992. A transport entity may concatenate TPDUs from the same or different transport 
  1993. connections while maintaining the order of TPDUs for a given 
  1994. transport connection compatible with the protocol operation.
  1995. .PP
  1996. A valid set of concatenated TPDUs may contain:
  1997. .RT
  1998. .LP
  1999.     a)
  2000.     any number of TPDUs from the following list: AK, EA, RJ,
  2001. ER, DC\ TPDUs provided that these TPDUs come from different
  2002. transport connections;
  2003. .LP
  2004.     b)
  2005.     no more than one TPDU from the following list: CR, DR, CC,
  2006. DT, ED\ TPDUs; if this TPDU is present, it shall be placed last
  2007. in the set of concatenated TPDUs.
  2008. .PP
  2009. A transport entity shall accept a valid set of concatenated
  2010. TPDUs.
  2011. .PP
  2012. \fINote\ 1\fR \ \(em\ The TPDUs within a concatenated set may be distinguished 
  2013. by means of the length indicator parameter. 
  2014. .PP
  2015. \fINote\ 2\fR \ \(em\ The end of a TPDU containing data is indicated by the
  2016. termination of the NSDU.
  2017. .PP
  2018. \fINote\ 3\fR \ \(em\ The number of concatenated TPDUs referred to in \(sc\ 
  2019. 6.4.2\ a) is bounded by the maximum number of transport connections which 
  2020. are multiplexed together, except during assignment or reassignment. 
  2021. .RT
  2022. .sp 2P
  2023. .LP
  2024. 6.5
  2025.     \fIConnection establishment\fR 
  2026. .sp 1P
  2027. .RT
  2028. .sp 1P
  2029. .LP
  2030. 6.5.1
  2031.     \fIPurpose\fR 
  2032. .sp 9p
  2033. .RT
  2034. .PP
  2035. The procedure for connection establishment is used in all classes to create 
  2036. a new transport connection. 
  2037. .RT
  2038. .sp 1P
  2039. .LP
  2040. 6.5.2
  2041.     \fINetwork service primitives\fR 
  2042. .sp 9p
  2043. .RT
  2044. .PP
  2045. The procedure uses the following network service
  2046. primitive:
  2047. .RT
  2048. .LP
  2049.     N\(hyDATA.
  2050. .sp 1P
  2051. .LP
  2052. 6.5.3
  2053.     \fITPDUs and parameters used\fR 
  2054. .sp 9p
  2055. .RT
  2056. .PP
  2057. The procedure uses the following TPDUs and parameters:
  2058. .RT
  2059. .LP
  2060.     a)
  2061.     CR TPDU;
  2062. .LP
  2063.     \(em
  2064.     CDT;
  2065. .LP
  2066.     \(em
  2067.     DST\(hyREF (set to zero);
  2068. .LP
  2069.     \(em
  2070.     SRC\(hyREF;
  2071. .LP
  2072.     \(em
  2073.     CLASS and OPTIONS (preferred), i.e.:
  2074. .LP
  2075.     i)
  2076.     class,
  2077. .LP
  2078.     ii)
  2079.     use of extended format,
  2080. .LP
  2081.     iii)
  2082.     non\(hyuse of explicit flow control in Class 2;
  2083. .LP
  2084.     \(em
  2085.     calling TSAP\(hyID;
  2086. .LP
  2087.     \(em
  2088.     called TSAP\(hyID;
  2089. .LP
  2090.     \(em
  2091.     TPDU size (proposed);
  2092. .LP
  2093.     \(em
  2094.     version number;
  2095. .LP
  2096.     \(em
  2097.     protection parameter;
  2098. .LP
  2099.     \(em
  2100.     checksum;
  2101. .LP
  2102.     \(em
  2103.     additional option selection (preferred), i.e.:
  2104. .LP
  2105.     i)
  2106.     use of network expedited in Class 1,
  2107. .LP
  2108.     ii) 
  2109.     use of receipt confirmation in Class 1,
  2110. .LP
  2111.     iii)
  2112.     non\(hyuse of checksums in Class 4,
  2113. .LP
  2114.     iv) 
  2115.     use of transport expedited data transfer
  2116. service;
  2117. .bp
  2118. .LP
  2119.     \(em
  2120.     alternative protocol class(es);
  2121. .LP
  2122.     \(em
  2123.     acknowledge time;
  2124. .LP
  2125.     \(em
  2126.     throughput (proposed);
  2127. .LP
  2128.     \(em
  2129.     residual error rate (proposed);
  2130. .LP
  2131.     \(em
  2132.     priority (proposed);
  2133. .LP
  2134.     \(em
  2135.     transit delay (proposed);
  2136. .LP
  2137.     \(em
  2138.     reassignment time;
  2139. .LP
  2140.     \(em
  2141.     user data.
  2142. .LP
  2143.     b)
  2144.     CC TPDU;
  2145. .LP
  2146.     \(em
  2147.     CDT;
  2148. .LP
  2149.     \(em
  2150.     DST\(hyREF;
  2151. .LP
  2152.     \(em
  2153.     SRC\(hyREF;
  2154. .LP
  2155.     \(em
  2156.     CLASS and OPTIONS (selected);
  2157. .LP
  2158.     \(em
  2159.     calling TSAP\(hyID;
  2160. .LP
  2161.     \(em
  2162.     called TSAP\(hyID;
  2163. .LP
  2164.     \(em
  2165.     TPDU size (selected);
  2166. .LP
  2167.     \(em
  2168.     protection parameter;
  2169. .LP
  2170.     \(em
  2171.     checksum;
  2172. .LP
  2173.     \(em
  2174.     additional option selection (selected);
  2175. .LP
  2176.     \(em
  2177.     acknowledge time;
  2178. .LP
  2179.     \(em
  2180.     throughput (selected);
  2181. .LP
  2182.     \(em
  2183.     residual error rate (selected);
  2184. .LP
  2185.     \(em
  2186.     priority (selected);
  2187. .LP
  2188.     \(em
  2189.     transit delay (selected);
  2190. .LP
  2191.     \(em
  2192.     user data.
  2193. .sp 1P
  2194. .LP
  2195. 6.5.4
  2196.     \fIProcedure\fR 
  2197. .sp 9p
  2198. .RT
  2199. .PP
  2200. A transport connection is established by means of one transport
  2201. entity (the \fIinitiator\fR ) transmitting a CR\ TPDU to the other transport 
  2202. entity (the \fIresponder\fR ), which replies with a CC\ TPDU. Before sending 
  2203. the CR\ TPDU, 
  2204. the initiator assigns the transport connection being created to one (or
  2205. more if the splitting procedure is being used) network connection(s). It is
  2206. this set of network connections over which the TPDUs are sent.
  2207. .PP
  2208. \fINote\fR \ \(em\ Even if the initiator assigns the transport connection to
  2209. more than one network connection, all the CR TPDUs (if repeated) or DR TPDUs
  2210. with DST\(hyREF set to zero which are sent prior to the receipt of the 
  2211. CC\ TPDU, 
  2212. shall be sent on the same network connection, unless an N\(hyDISCONNECT 
  2213. indication is received. (This is necessary because the remote entity may 
  2214. not support 
  2215. Class\ 4 and therefore may not recognize splitting.) If the initiator has 
  2216. made other assignments, it will use them only after receipt of a Class\ 
  2217. 4 CC\ TPDU 
  2218. (see also the splitting procedure \(sc\ 6.23).
  2219. .PP
  2220. During this exchange, all information and parameters needed for the
  2221. transport entities to operate shall be exchanged or negotiated.
  2222. .PP
  2223. \fINote\ 1\fR \ \(em\ The transport protocol identification procedures 
  2224. specified in Annex\ B may need to be considered in conjunction with this 
  2225. procedure. 
  2226. .PP
  2227. \fINote\ 2\fR \ \(em\ Except in Class 4, it is suggested that the initiator 
  2228. start an optional timer TS1 at the time the CR\ TPDU is sent. This timer 
  2229. should be 
  2230. stopped when the connection is considered as accepted or refused or
  2231. unsuccessful. If the timer expires, the initiator should reset or disconnect
  2232. the network connection and, in Classes\ 1 and\ 3, freeze the reference (see
  2233. \(sc\ 6.18). For all other transport connection(s) multiplexed on the same 
  2234. network connection, the procedures for reset or disconnect as appropriate 
  2235. should be 
  2236. followed.
  2237. .PP
  2238. When an unexpected duplicated CR TPDU is received (with Class 4 as
  2239. preferred class), it shall be ignored in Classes\ 0, 1, 2 and\ 3 and a CC\ TPDU
  2240. shall be returned in Class\ 4.
  2241. .PP
  2242. After receiving the CC TPDU for a class which includes the procedure for 
  2243. retention until acknowledgment of TPDUs, the initiator shall acknowledge 
  2244. the CC\ TPDU as defined in Table\ 5/X.224 (see \(sc\ 6.13).
  2245. .bp
  2246. .PP
  2247. When the network expedited variant of expedited data transfer (see
  2248. \(sc\ 6.11) has been agreed (possible in Class\ 1 only), the responder 
  2249. shall not 
  2250. send an ED\ TPDU before the CC\ TPDU is acknowledged.
  2251. .PP
  2252. The following information is exchanged:
  2253. .RT
  2254. .LP
  2255.     a)
  2256.     \fIreferences\fR \ \(em\ Each transport entity chooses a reference to
  2257. be used by the peer entity which is 16\ bits long and which is
  2258. arbitrary except for the following restrictions:
  2259. .LP
  2260.     1)
  2261.     it shall not already be in use or frozen (see
  2262. \(sc\ 6.18),
  2263. .LP
  2264.     2)
  2265.     it shall not be zero.
  2266. .LP
  2267.     This mechanism is symmetrical and provides identification of
  2268. the transport connection independent of the network connection.
  2269. The range of references used for transport connections, in a
  2270. given transport entity, is a local matter.
  2271. .LP
  2272.     b)
  2273.     \fIcalling and called TSAPs\(hyIDs\fR \| (optional)\ \(em\ Indicate the
  2274. calling and called transport service access points. When either
  2275. network address unambiguously defines the transport address,
  2276. this information may be omitted.
  2277. .LP
  2278.     c)
  2279.     \fIinitial credit\fR \ \(em\ Only relevant for classes which include
  2280. the explicit flow control function.
  2281. .LP
  2282.     d)
  2283.     \fIuser data\fR \ \(em\ Not available if Class 0 is the preferred
  2284. class (see Note). Up to 32\ octets in other classes.
  2285. .LP
  2286.     \fINote\fR \ \(em\ If Class 0 is a valid response according to
  2287. Table\ 3/X.224, inclusion of user data in the CR\ TPDU may cause
  2288. the responding entity to refuse the connection (e.g.\ if it only
  2289. supports Class\ 0).
  2290. .LP
  2291.     e)
  2292.     \fIacknowledgment time\fR \ \(em\ Only in Class 4.
  2293. .LP
  2294.     f
  2295. )
  2296.     \fIchecksum parameter\fR \ \(em\ Only in Class 4.
  2297. .LP
  2298.     g)
  2299.     \fIprotection parameter\fR \ \(em\ This parameter and its semantics
  2300. are user defined.
  2301. .ce
  2302. \fBH.T. [T3.224]\fR 
  2303. .ce
  2304. TABLE\ 3/X.224
  2305. .ce
  2306. \fBValid responses corresponding to preferred and any\fR 
  2307. .ce
  2308. \fBalternative class proposed in the CR TPDU\fR 
  2309. .T&
  2310. lw(30p) | lw(36p) | lw(30p) | lw(36p) | lw(30p) | lw(36p) | lw(30p) .
  2311.                         
  2312. .TE
  2313. .nr PS 9
  2314. .RT
  2315. .ad r
  2316. \fBTable 3/X.224 [T3.224], p.\fR 
  2317. .sp 1P
  2318. .RT
  2319. .ad b
  2320. .RT
  2321. .LP
  2322. .bp
  2323. .LP
  2324.     The following negotiations take place:
  2325. .LP
  2326.     h)
  2327.     \fIprotocol class\fR \ \(em\ The initiator shall propose a preferred
  2328. class and any number of alternative classes which permit a
  2329. valid response as defined in Table\ 3/X.224. The initiator should
  2330. assume when it sends the CR\ TPDU that its preferred class will
  2331. be agreed to, and commence the procedures associated with that
  2332. class, except that if Class\ 0 or Class\ 1 is an alternative
  2333. class, multiplexing shall not commence until a CC\ TPDU selecting
  2334. the use of Classes\ 2, 3 or\ 4 has been received.
  2335. .LP
  2336.     \fINote\fR \ \(em\ This means, for example, that when the preferred
  2337. class includes resynchronization (see \(sc\ 6.14), the
  2338. resynchronization will occur if a reset is signalled during
  2339. connection establishment.
  2340. .LP
  2341.     The responder shall select one class defined in
  2342. Table\ 3/X.224 as a valid response corresponding to the preferred
  2343. class and to the class(es), if any, contained in the alternative
  2344. class parameter of the CR\ TPDU. It shall indicate the selected
  2345. class in the CC\ TPDU and shall follow the procedures for the
  2346. selected class.
  2347. .LP
  2348.     If the preferred class is not selected, then on receipt of
  2349. the CC\ TPDU, the initiator shall adjust its operation according
  2350. to the procedures of the selected class.
  2351. .LP
  2352.     i)
  2353.     \fITPDU size\fR \ \(em\ The initiator may propose a maximum size for
  2354. TPDUs, and the responder may accept this value or respond with
  2355. any value between\ 128 and the proposed value in the set of
  2356. values available for the class (see \(sc\ 13.3.4\ b)).
  2357. .LP
  2358.     \fINote\fR \ \(em\ The length of the CR TPDU does not exceed 128
  2359. octets (see \(sc\ 13.3).
  2360. .LP
  2361.     j)
  2362.     \fInormal or extended format\fR \ \(em\ Either normal or extended is
  2363. available. When extended is used, this applies to CDT, TPDU\(hyNR,
  2364. ED\(hyTPDU\(hyNR, YR\(hyTU\(hyNR and YR\(hyEDTU\(hyNR parameters.
  2365. .LP
  2366.     k)
  2367.     \fIchecksum selection\fR \ \(em\ This defines whether or not TPDUs of
  2368. the connection are to include a checksum.
  2369. .LP
  2370.     l)
  2371.     \fIquality of service parameters\fR \ \(em\ This defines the
  2372. throughput, transit delay, priority, and residual error
  2373. rate.
  2374. .LP
  2375.     \fINote\fR \ \(em\ The transport service defines transit delay as
  2376. requiring a previously stated average TSDU size as a basis for
  2377. any specification. The protocol, as specified in \(sc\ 13.3.4,\ l),
  2378. uses a value of 128\ octets. Conversion to and from
  2379. specifications based upon some other value is a local
  2380. matter.
  2381. .LP
  2382.     m)
  2383.     \fIthe non\(hyuse of explicit flow control\fR in Class 2.
  2384. .LP
  2385. \fB\fB\fB\fB\fB\fB\fB\fB\fB
  2386.     n)
  2387.      \fIthe use of network receipt confirmation and network\fR \fIexpedited\fR 
  2388. \| when Class\ 1 is to be used. 
  2389. .LP
  2390.     o)
  2391.     \fIthe use of expedited data transfer service\fR \ \(em\ This allows
  2392. both TS\(hyusers to negotiate the use or non\(hyuse of the expedited
  2393. data transport service as defined in the transport service
  2394. definition [2].
  2395. .LP
  2396.     The following information is set only in the CR TPDU:
  2397. .LP
  2398.     p)
  2399.     \fIversion number\fR \ \(em\ This defines the version of the transport
  2400. protocol used for this connection.
  2401. .LP
  2402.     q)
  2403.     \fIreassignment time parameter\fR \ \(em\ This indicates the time for
  2404. which the initiator will persist in following the
  2405. reassignment after failure procedure.
  2406. .PP
  2407. The negotiation rules for the options are such that the initiator may propose 
  2408. either to use or not to use the option. The responder may either 
  2409. accept the proposed choice or select an alternative choice as defined in
  2410. Table\ 4/X.224.
  2411. .PP
  2412. When a parameter [which is valid for the proposed class(es)] is
  2413. absent and a default value is defined in this Recommendation, this
  2414. is equivalent to the presence of the parameter with the default value.
  2415. .PP
  2416. In Class 2, whenever a transport entity requests or agrees to the
  2417. transport expedited data transfer service or to the use of extended formats,
  2418. it shall request or agree (respectively) to the use of explicit flow
  2419. control.
  2420. .RT
  2421. .sp 2P
  2422. .LP
  2423. 6.6
  2424.     \fIConnection refusal\fR 
  2425. .sp 1P
  2426. .RT
  2427. .sp 1P
  2428. .LP
  2429. 6.6.1
  2430.     \fIPurpose\fR 
  2431. .sp 9p
  2432. .RT
  2433. .PP
  2434. The connection refusal procedure is used in all classes when a
  2435. transport entity refuses a transport connection in response to a
  2436. CR\ TPDU.
  2437. .bp
  2438. .RT
  2439. .ce
  2440. \fBH.T. [T4.224]\fR 
  2441. .ce
  2442. TABLE\ 4/X.224
  2443. .ce
  2444. \fBNegotiation of options during connection establishment\fR 
  2445. .ps 9
  2446. .vs 11
  2447. .nr VS 11
  2448. .nr PS 9
  2449. .TS
  2450. center box;
  2451. lw(96p) | lw(48p) | lw(48p) .
  2452.         
  2453. .TE
  2454. .nr PS 9
  2455. .RT
  2456. .ad r
  2457. \fBTableau 4/X.224 [T4.224], p. 6\fR 
  2458. .sp 1P
  2459. .RT
  2460. .ad b
  2461. .RT
  2462. .sp 1P
  2463. .LP
  2464. 6.6.2
  2465.     \fITPDUs and parameters used\fR 
  2466. .sp 9p
  2467. .RT
  2468. .PP
  2469. The procedure makes use of the following TPDUs and
  2470. parameters:
  2471. .RT
  2472. .LP
  2473.     a)
  2474.     DR TPDU:
  2475. .LP
  2476.     \(em
  2477.     SRC\(hyREF;
  2478. .LP
  2479.     \(em
  2480.     reason;
  2481. .LP
  2482.     \(em
  2483.     user data.
  2484. .LP
  2485.     b)
  2486.     ER TPDU:
  2487. .LP
  2488.     \(em
  2489.     reject cause;
  2490. .LP
  2491.     \(em
  2492.     invalid TPDU.
  2493. .sp 1P
  2494. .LP
  2495. 6.6.3
  2496.     \fIProcedure\fR 
  2497. .sp 9p
  2498. .RT
  2499. .PP
  2500. If a transport connection cannot be accepted, the responder shall respond 
  2501. to the CR\ TPDU with a DR\ TPDU. The reason shall indicate why the 
  2502. connection was not accepted. The source reference field in the DR\ TPDU 
  2503. shall be set to zero to indicate an unassigned reference. 
  2504. .PP
  2505. If a DR TPDU is received, the initiator shall regard the connection as 
  2506. released. 
  2507. .PP
  2508. The responder shall respond to an invalid CR TPDU by sending an ER or DR\ 
  2509. TPDU. If an ER\ TPDU is received in response to a CR\ TPDU, the initiator 
  2510. shall regard the connection as released.
  2511. .PP
  2512. \fINote\ 1\fR \ \(em\ When the invalid CR TPDU can be identified as having
  2513. Class\ 0 as the preferred class, it is suggested to respond with an ER\ 
  2514. TPDU. For all other invalid CR\ TPDUs, either an ER\ TPDU or DR\ TPDU may 
  2515. be sent. 
  2516. .PP
  2517. \fINote\ 2\fR \ \(em\ If the optional supervisory timer TS1 has been set for
  2518. this connection, then the initiator should stop the timer on receipt of 
  2519. the DR or ER\ TPDU. 
  2520. .bp
  2521. .RT
  2522. .sp 2P
  2523. .LP
  2524. 6.7
  2525.     \fINormal release\fR 
  2526. .sp 1P
  2527. .RT
  2528. .sp 1P
  2529. .LP
  2530. 6.7.1
  2531.     \fIPurpose\fR 
  2532. .sp 9p
  2533. .RT
  2534. .PP
  2535. The release procedure is used by a transport entity in order to
  2536. terminate a transport connection. The implicit variant is used only in 
  2537. Class\ 0. The explicit variant is used in Classes\ 1, 2, 3 and\ 4. 
  2538. .PP
  2539. \fINote\ 1\fR \ \(em\ When the implicit variant is used (i.e. in Class\ 0), the
  2540. lifetime of the transport connection is directly correlated with the lifetime 
  2541. of the network connection. 
  2542. .PP
  2543. \fINote\ 2\fR \ \(em\ The use of the explicit variant of the release procedure
  2544. enables the transport connection to be released independently of the underlying 
  2545. network connection. 
  2546. .RT
  2547. .sp 1P
  2548. .LP
  2549. 6.7.2
  2550.     \fINetwork service primitives\fR 
  2551. .sp 9p
  2552. .RT
  2553. .PP
  2554. The procedure makes use of the following network service
  2555. primitives:
  2556. .RT
  2557. .LP
  2558.     a)
  2559.     N\(hyDISCONNECT (implicit variant only),
  2560. .LP
  2561.     b)
  2562.     N\(hyDATA.
  2563. .sp 1P
  2564. .LP
  2565. 6.7.3
  2566.     \fITPDUs and parameters used\fR 
  2567. .sp 9p
  2568. .RT
  2569. .PP
  2570. The procedure makes use of the following TPDUs and parameters:
  2571. .RT
  2572. .LP
  2573.     a)
  2574.     DR TPDU:
  2575. .LP
  2576.     \(em
  2577.     reason;
  2578. .LP
  2579.     \(em
  2580.     user data;
  2581. .LP
  2582.     \(em
  2583.     SRC\(hyREF;
  2584. .LP
  2585.     \(em
  2586.     DST\(hyREF.
  2587. .LP
  2588.     b)
  2589.     DC TPDU.
  2590. .sp 1P
  2591. .LP
  2592. 6.7.4
  2593.     \fIProcedure for implicit variant\fR 
  2594. .sp 9p
  2595. .RT
  2596. .PP
  2597. In the implicit variant, either transport entity disconnects a
  2598. transport connection by disconnecting the network connection to which it is
  2599. assigned. When a transport entity receives an N\(hyDISCONNECT indication, this
  2600. should be considered as the release of the transport connection.
  2601. .RT
  2602. .sp 1P
  2603. .LP
  2604. 6.7.5
  2605.     \fIProcedure for explicit variant\fR 
  2606. .sp 9p
  2607. .RT
  2608. .PP
  2609. When the release of a transport connection is to be initiated, a
  2610. transport entity:
  2611. .RT
  2612. .LP
  2613.     a)
  2614.     if it has previously sent or received a CC TPDU (see
  2615. Note\ 1), shall:
  2616. .LP
  2617.     1)
  2618.     send a DR TPDU;
  2619. .LP
  2620.     2)
  2621.     discard all subsequently received TPDUs other than a
  2622. DR or DC\ TPDU;
  2623. .LP
  2624.     3)
  2625.     consider the transport connection released on receipt
  2626. of a DR or DC\ TPDU;
  2627. .LP
  2628.     b)
  2629.     if a) is not applicable, it shall:
  2630. .LP
  2631.     1)
  2632.     for classes other than Class\ 4, wait for
  2633. acknowledgment of the outstanding CR\ TPDU; if it receives a
  2634. CC\ TPDU, it shall follow the procedure in \(sc\ 6.7.5\ a);
  2635. .LP
  2636.     2)
  2637.     for Class 4, either send a DR\ TPDU with a zero value
  2638. in the DST\(hyREF field, or follow the procedure in
  2639. \(sc\ 6.7.5\ b)\ 1).
  2640. .LP
  2641.     In the former case, receipt of a CC TPDU specifying
  2642. Class 4 will be ignored. Receipt of a CC\ TPDU with another class will
  2643. be processed as follows: if the class is\ 0, the network
  2644. connection shall be disconnected; otherwise, a DR\ TPDU with
  2645. the DST\(hyREF field set to the value of the SRC\(hyREF field of the
  2646. received CC\ TPDU shall be sent and the release procedure of
  2647. the class is continued.
  2648. .bp
  2649. .LP
  2650.     A transport entity that receives a DR TPDU shall:
  2651. .LP
  2652.     c)
  2653.     if it has previously sent a DR TPDU for the same
  2654. transport connection, consider the transport connection
  2655. released;
  2656. .LP
  2657.     d)
  2658.     if it has previously sent a CR TPDU that has not been
  2659. acknowledged by a CC\ TPDU, consider the connection
  2660. refused (see \(sc\ 6.6);
  2661. .LP
  2662.     If the SRC\(hyREF is not zero, a DC\ TPDU shall be sent
  2663. using the SRC\(hyREF as the DST\(hyREF.
  2664. .LP
  2665.     \fINote\fR \ \(em\ In this case, the DR TPDU has been associated
  2666. regardless of its SRC\(hyREF field (see \(sc\ 6.9.4).
  2667. .LP
  2668.     e)
  2669.     if c) and d) are not applicable, send a DC TPDU and consider
  2670. the transport connection released. If the received DR has the
  2671. DST\(hyREF field set to zero, then a DC with SRC\(hyREF set to zero
  2672. shall be sent, regardless of the local reference. If the entity
  2673. receiving such a DR\ TPDU has previously decided to negotiate
  2674. down the class, this entity is always entitled to consider
  2675. such a DR\ TPDU as spurious. Since no association has been made,
  2676. the transport connection is not released at the responder side
  2677. but the CC\ TPDU, when sent, will be answered by a DR\ TPDU
  2678. (spurious CC\ TPDU).
  2679. .PP
  2680. \fINote\ 1\fR \ \(em\ This requirement ensures that the transport entity 
  2681. is aware of the remote reference for the transport connection. 
  2682. .PP
  2683. \fINote\ 2\fR \ \(em\ When the transport connection is considered as released,
  2684. the local reference is either available for re\(hyuse or is frozen
  2685. (see
  2686. \(sc\ 6.18).
  2687. .PP
  2688. \fINote\ 3\fR \ \(em\ After the release of a transport connection, the network
  2689. connection can be released or retained to enable its re\(hyuse for the 
  2690. assignment of other transport connections (see \(sc\ 6.1). 
  2691. .PP
  2692. \fINote\ 4\fR \ \(em\ Except in Class 4, it is suggested that if a transport
  2693. entity does not receive acknowledgment of a DR\ TPDU within time TS2, it 
  2694. should either reset or disconnect the network connection, and freeze the 
  2695. reference 
  2696. when appropriate (see \(sc\ 6.18). For all other transport connection(s)
  2697. multiplexed on the same network connection, the procedures for reset or
  2698. disconnect as appropriate should be followed.
  2699. .PP
  2700. \fINote\ 5\fR \ \(em\ When a transport entity is waiting for a CC TPDU before
  2701. sending a DR\ TPDU and the network connection is reset or released, it should
  2702. consider the transport connection released and, in classes other than Classes\ 
  2703. 0 and\ 2, freeze the reference (see \(sc\ 6.18). 
  2704. .RT
  2705. .sp 2P
  2706. .LP
  2707. 6.8
  2708.     \fIError release\fR 
  2709. .sp 1P
  2710. .RT
  2711. .sp 1P
  2712. .LP
  2713. 6.8.1
  2714.     \fIPurpose\fR 
  2715. .sp 9p
  2716. .RT
  2717. .PP
  2718. This procedure is used only in Classes\ 0 and\ 2 to release a
  2719. transport connection on the receipt of a N\(hyDISCONNECT or N\(hyRESET
  2720. indication.
  2721. .RT
  2722. .sp 1P
  2723. .LP
  2724. 6.8.2
  2725.     \fINetwork service primitives\fR 
  2726. .sp 9p
  2727. .RT
  2728. .PP
  2729. The procedure makes use of the following service
  2730. primitives:
  2731. .RT
  2732. .LP
  2733.     a)
  2734.     N\(hyDISCONNECT indication;
  2735. .LP
  2736.     b)
  2737.     N\(hyRESET indication.
  2738. .sp 1P
  2739. .LP
  2740. 6.8.3
  2741.     \fIProcedure\fR 
  2742. .sp 9p
  2743. .RT
  2744. .PP
  2745. When, on the network connection to which a transport connection is assigned, 
  2746. an N\(hyDISCONNECT or N\(hyRESET indication is received, both transport 
  2747. entities shall consider that the transport connection is released, and so
  2748. inform the TS\(hyusers.
  2749. .PP
  2750. \fINote\fR \ \(em\ In other classes, since error recovery is used, the 
  2751. receipt of an N\(hyRESET indication or N\(hyDISCONNECT indication will 
  2752. result in the 
  2753. invocation of the error recovery procedure.
  2754. .RT
  2755. .sp 2P
  2756. .LP
  2757. 6.9
  2758.     \fIAssociation of\fR 
  2759. \fITPDUs with transport connections\fR 
  2760. .sp 1P
  2761. .RT
  2762. .sp 1P
  2763. .LP
  2764. 6.9.1
  2765.     \fIPurpose\fR 
  2766. .sp 9p
  2767. .RT
  2768. .PP
  2769. This procedure is used in all classes to interpret a received NSDU as TPDU(s) 
  2770. and, if possible, to associate each such TPDU with a transport 
  2771. connection.
  2772. .bp
  2773. .RT
  2774. .sp 1P
  2775. .LP
  2776. 6.9.2
  2777.     \fINetwork service primitives\fR 
  2778. .sp 9p
  2779. .RT
  2780. .PP
  2781. This procedure makes use of the following network service
  2782. primitives:
  2783. .RT
  2784. .LP
  2785.     a)
  2786.     N\(hyDATA indication;
  2787. .LP
  2788.     b)
  2789.     N\(hyEXPEDITED DATA indication.
  2790. .sp 1P
  2791. .LP
  2792. 6.9.3
  2793.     \fITPDUs and parameters used\fR 
  2794. .sp 9p
  2795. .RT
  2796. .PP
  2797. This procedure makes use of the following TPDUs and
  2798. parameters:
  2799. .RT
  2800. .LP
  2801.     a)
  2802.     in any TPDU except: CR TPDU; DT TPDU in Classes\ 0 or\ 1;
  2803. AK TPDU in Class\ 1:
  2804. .LP
  2805.     \(em
  2806.     DST\(hyREF.
  2807. .LP
  2808.     b)
  2809.     CR, CC, DR and DC TPDUs:
  2810. .LP
  2811.     \(em
  2812.     SRC\(hyREF.
  2813. .LP
  2814.     c)
  2815.     DT TPDU in Classes 0 or 1 and AK TPDU in
  2816. Class 1.
  2817. .sp 2P
  2818. .LP
  2819. 6.9.4
  2820.     \fIProcedures\fR 
  2821. .sp 1P
  2822. .RT
  2823. .sp 1P
  2824. .LP
  2825. 6.9.4.1
  2826.     \fIIdentification of TPDUs\fR 
  2827. .sp 9p
  2828. .RT
  2829. .PP
  2830. If the received NSDU or expedited NSDU cannot be decoded (i.e.\ does not 
  2831. contain one or more correct TPDUs) or is corrupted (i.e.\ contains a TPDU 
  2832. with a wrong checksum) then the transport entity shall:
  2833. .RT
  2834. .LP
  2835.     a)
  2836.     if the network connection on which the error is detected has
  2837. a Class\ 0 or Class\ 1 transport connection assigned to it, then
  2838. treat as a protocol error (see \(sc\ 6.22) for that transport
  2839. connection;
  2840. .LP
  2841.     b)
  2842.     otherwise:
  2843. .LP
  2844.     1)
  2845.     if the NSDU can be decoded but contains corrupted
  2846. TPDUs, discard the TPDUs (Class\ 4 only) and optionally
  2847. apply \(sc\ 6.9.4.1\ b)\ 2);
  2848. .LP
  2849.     2)
  2850.     if the NSDU cannot be decoded, issue an N\(hyRESET (or
  2851. N\(hyDISCONNECT) request for the network connection and
  2852. for all of the transport connections assigned to this
  2853. network connection (if any), apply the procedures
  2854. defined for handling of network signalled reset or
  2855. disconnect.
  2856. .LP
  2857.     If the NSDU can be decoded and is not corrupted, the transport
  2858. entity shall:
  2859. .LP
  2860.     c)
  2861.     if the network connection on which the NSDU was received has
  2862. a Class\ 0 transport connection assigned to it, then consider
  2863. the NSDU as forming one TPDU and associate the TPDU with the
  2864. transport connection (see \(sc\ 6.9.4.2);
  2865. .LP
  2866.     d)
  2867.     otherwise, invoke the separation procedures and for each of
  2868. the individual TPDUs in the order in which they appear in the
  2869. NSDU apply the procedure defined in \(sc\ 6.9.4.2.
  2870. .sp 1P
  2871. .LP
  2872. 6.9.4.2
  2873.     \fIAssociation of individual TPDUs\fR 
  2874. .sp 9p
  2875. .RT
  2876. .PP
  2877. If the received TPDU is a CR TPDU, then, if it is a duplicate as
  2878. recognized by using the NSAPs of the network connection, and the SRC\(hyREF
  2879. parameter, then it is associated with the transport connection created 
  2880. by the original copy of the CR\ TPDU; otherwise, it is processed as requesting 
  2881. the 
  2882. creation of a new transport connection.
  2883. .PP
  2884. If the received TPDU is a DT TPDU and the network connection has a
  2885. Class\ 0 or Class\ 1 transport connection assigned to it, or an AK\ TPDU 
  2886. where a Class\ 1 transport connection is assigned, then the TPDU is associated 
  2887. with the transport connection. 
  2888. .PP
  2889. Otherwise, the DST\(hyREF parameter of the TPDU is used to identify the 
  2890. transport connection. The following cases are distinguished: 
  2891. .RT
  2892. .LP
  2893.     a)
  2894.     If the DST\(hyREF is not allocated to a transport connection,
  2895. the transport entity shall respond on the same network
  2896. connection with a DR\ TPDU if the TPDU is a CC\ TPDU, with a
  2897. DC\ TPDU if the TPDU is a DR\ TPDU and shall discard the TPDU
  2898. if neither a DR\ TPDU nor CC\ TPDU. No association with a
  2899. transport connection is made.
  2900. .LP
  2901.     \fINote\fR \ \(em\ If the DR TPDU is carrying an SRC\(hyREF field set to
  2902. zero, then no DC TPDU shall be sent.
  2903. .bp
  2904. .LP
  2905.     b)
  2906.     If the DST\(hyREF is allocated to a connection, but the TPDU is
  2907. received on a network connection to which the connection has not
  2908. been assigned, then there are three cases:
  2909. .LP
  2910.     1)
  2911.     if the transport connection is of Class\ 4 and if the
  2912. TPDU is received on a network connection with the same
  2913. pair of NSAPs as that of the CR\ TPDU, then the TPDU is
  2914. associated with this transport connection and considered
  2915. as performing assignment;
  2916. .LP
  2917.     2)
  2918.     if the transport connection is not assigned to any
  2919. network connection (waiting for reassignment after
  2920. failure) and if the TPDU is received on a network
  2921. connection with the same pair of NSAPs as that of the
  2922. CR\ TPDU, then the association with that transport
  2923. connection is made except in the case of DC, DR and
  2924. CC\ TPDUs which are respectively described in \(sc\ 6.9.4.2\ c),
  2925. d) and\ e);
  2926. .LP
  2927.     3)
  2928.     otherwise, the TPDU is considered as having a DST\(hyREF
  2929. not allocated to a transport connection [case\ a)].
  2930. .LP
  2931.     c)
  2932.     If the TPDU is a DC TPDU, then it is associated with the
  2933. transport connection to which the DST\(hyREF is allocated, unless
  2934. the SRC\(hyREF is not the expected one, in which case the DC\ TPDU
  2935. is discarded.
  2936. .LP
  2937.     d)
  2938.     If the TPDU is a DR TPDU then there are four cases:
  2939. .LP
  2940.     1)
  2941.     if the SRC\(hyREF is not as expected, then a DC TPDU with
  2942. a DST\(hyREF equal to the SRC\(hyREF of the received DR\ TPDU is
  2943. sent back and no association is made;
  2944. .LP
  2945.     2)
  2946.     if a CR TPDU is unacknowledged, then the DR TPDU is
  2947. associated with the transport connection, regardless of
  2948. the value of its SRC\(hyREF\ parameter;
  2949. .LP
  2950.     3)
  2951.     if the transport entity implements Class 4 and if the
  2952. DST\(hyREF is zero and there is an unacknowledged CC\ TPDU
  2953. or T\(hyCONNECT response is awaited, then the DR\ TPDU shall
  2954. be associated with the transport connection holding the
  2955. SRC\(hyREF as the remote reference;
  2956. .LP
  2957.     4)
  2958.     otherwise, the DR TPDU is associated with the
  2959. transport connection identified by the DST\(hyREF
  2960. parameter.
  2961. .LP
  2962.     e)
  2963.     If the TPDU is a CC TPDU whose DST\(hyREF parameter identifies
  2964. an open connection (one for which a CC TPDU has been previously
  2965. received), and the SRC\(hyREF in the CC\ TPDU does not match the
  2966. remote reference, then a DR\ TPDU is sent back with DST\(hyREF equal
  2967. to the SRC\(hyREF of the received CC\ TPDU and no association is
  2968. made.
  2969. .LP
  2970.     f
  2971. )
  2972.     If none of the above cases apply, then the TPDU is
  2973. associated with the transport connection identified by the
  2974. DST\(hyREF parameter.
  2975. .sp 2P
  2976. .LP
  2977. 6.10
  2978.     \fIData TPDU numbering\fR 
  2979. .sp 1P
  2980. .RT
  2981. .sp 1P
  2982. .LP
  2983. 6.10.1
  2984.     \fIPurpose\fR 
  2985. .sp 9p
  2986. .RT
  2987. .PP
  2988. Data TPDU numbering is used in Classes\ 1, 2 (except when the
  2989. non\(hyuse of explicit flow control option is selected), 3 and\ 4. Its purpose
  2990. is to enable the use of recovery, flow control and resequencing
  2991. functions.
  2992. .RT
  2993. .sp 1P
  2994. .LP
  2995. 6.10.2
  2996.     \fITPDUs and parameters used\fR 
  2997. .sp 9p
  2998. .RT
  2999. .PP
  3000. This procedure makes use of the following TPDU and
  3001. parameter:
  3002. .RT
  3003. .LP
  3004.     DT TPDU;
  3005. .LP
  3006.     \(em
  3007.     TPDU\(hyNR.
  3008. .sp 1P
  3009. .LP
  3010. 6.10.3
  3011.     \fIProcedure\fR 
  3012. .sp 9p
  3013. .RT
  3014. .PP
  3015. A transport entity shall allocate the sequence number zero to the TPDU\(hyNR 
  3016. of the first DT TPDU which it transmits for a transport connection. For 
  3017. subsequent DT\ TPDUs sent on the same transport connection, the transport 
  3018. entity shall allocate a sequence number one greater than the previous one. 
  3019. .PP
  3020. When a DT TPDU is retransmitted, the TPDU\(hyNR parameter shall have the 
  3021. same value as in the first transmission of that DT\ TPDU. 
  3022. .bp
  3023. .PP
  3024. Modulo 2\u7\d arithmetic shall be used when normal formats have been
  3025. selected and modulo\ 2\u3\d\u1\d arithmetic shall be used when extended formats
  3026. have been selected. In this Recommendation, the relationships \*Qgreater 
  3027. than\*U 
  3028. and \*Qless than\*U apply to a set of contiguous TPDU numbers whose range 
  3029. is less than the modulus and whose starting and finishing numbers are known. 
  3030. The term \*Qless than\*U means \*Qoccurring sooner in the window sequence\*U 
  3031. and the term 
  3032. \*Qgreater than\*U means \*Qoccurring later in the window sequence\*U.
  3033. .RT
  3034. .sp 2P
  3035. .LP
  3036. 6.11
  3037.     \fIExpedited data transfer\fR 
  3038. .sp 1P
  3039. .RT
  3040. .sp 1P
  3041. .LP
  3042. 6.11.1
  3043.     \fIPurpose\fR 
  3044. .sp 9p
  3045. .RT
  3046. .PP
  3047. Expedited data transfer procedures are selected during connection establishment. 
  3048. The network normal data variant may be used in Classes\ 1, 2, 3 and\ 4. 
  3049. The network expedited variant is only used in Class\ 1. 
  3050. .RT
  3051. .sp 1P
  3052. .LP
  3053. 6.11.2
  3054.     \fINetwork service primitives\fR 
  3055. .sp 9p
  3056. .RT
  3057. .PP
  3058. The procedure makes use of the following network service
  3059. primitives:
  3060. .RT
  3061. .LP
  3062.     a)
  3063.     N\(hyDATA;
  3064. .LP
  3065.     b)
  3066.     N\(hyEXPEDITED DATA.
  3067. .sp 1P
  3068. .LP
  3069. 6.11.3
  3070.     \fITPDUs and parameters used\fR 
  3071. .sp 9p
  3072. .RT
  3073. .PP
  3074. The procedure makes use of the following TPDUs and
  3075. parameters:
  3076. .RT
  3077. .LP
  3078.     a)
  3079.     ED TPDU:
  3080. .LP
  3081.     \(em
  3082.     ED\(hyTPDU\(hyNR.
  3083. .LP
  3084.     b)
  3085.     EA TPDU:
  3086. .LP
  3087.     \(em
  3088.     YR\(hyEDTU\(hyNR.
  3089. .sp 1P
  3090. .LP
  3091. 6.11.4
  3092.     \fIProcedure\fR 
  3093. .sp 9p
  3094. .RT
  3095. .PP
  3096. The TS\(hyuser data parameter of each T\(hyEXPEDITED DATA request shall 
  3097. be conveyed as the data field of an Expedited Data (ED) TPDU. 
  3098. .PP
  3099. Each ED TPDU received shall be acknowledged by an Expedited
  3100. Acknowledge (EA) TPDU.
  3101. .PP
  3102. No more than one ED TPDU shall remain unacknowledged at any time for each 
  3103. direction of a transport connection. 
  3104. .PP
  3105. An ED TPDU with a zero length data field shall be treated as a
  3106. protocol error.
  3107. .PP
  3108. \fINote\ 1\fR \ \(em\ The network normal data variant is used, except when the
  3109. network expedited variant (available in Class\ 1 only), has been agreed, in
  3110. which case ED and EA\ TPDUs are conveyed in the data fields of N\(hyEXPEDITED 
  3111. DATA primitives (see \(sc\ 6.2.3). 
  3112. .PP
  3113. \fINote\ 2\fR \ \(em\ No TPDUs can be transmitted using network expedited
  3114. until the CC\ TPDU becomes acknowledged, to prevent the network expedited 
  3115. from overtaking the CC\ TPDU. 
  3116. .RT
  3117. .sp 2P
  3118. .LP
  3119. 6.12
  3120.     \fIReassignment after failure\fR 
  3121. .sp 1P
  3122. .RT
  3123. .sp 1P
  3124. .LP
  3125. 6.12.1
  3126.     \fIPurpose\fR 
  3127. .sp 9p
  3128. .RT
  3129. .PP
  3130. The reassignment after failure procedure is used in Classes\ 1 and\ 3 to 
  3131. commence recovery from an NS\(hyprovider signalled disconnect. 
  3132. .RT
  3133. .sp 1P
  3134. .LP
  3135. 6.12.2
  3136.     \fINetwork service primitives\fR 
  3137. .sp 9p
  3138. .RT
  3139. .PP
  3140. The procedure uses the following network service
  3141. primitive:
  3142. .RT
  3143. .LP
  3144.     N\(hyDISCONNECT indication.
  3145. .bp
  3146. .sp 1P
  3147. .LP
  3148. 6.12.3
  3149.     \fIProcedure\fR 
  3150. .sp 9p
  3151. .RT
  3152. .PP
  3153. When an N\(hyDISCONNECT indication is received for the network
  3154. connection to which a transport connection is assigned, the initiator shall
  3155. apply one of the following alternatives:
  3156. .RT
  3157. .LP
  3158.     a)
  3159.     if the TTR timer has not already run out and no DR TPDU is
  3160. retained, then:
  3161. .LP
  3162.     1)
  3163.     assign the transport connection to a different network
  3164. connection (see \(sc\ 6.1) and start its TTR timer if not
  3165. already started;
  3166. .LP
  3167.     2)
  3168.     while waiting for the completion of assignment if:
  3169. .LP
  3170.     \(em
  3171.     an N\(hyDISCONNECT indication is received, repeat
  3172. the procedure from \(sc\ 6.12.3\ a),
  3173. .LP
  3174.     \(em
  3175.     the TTR timer expires, begin procedure
  3176. \(sc\ 6.12.3\ b);
  3177. .LP
  3178.     3)
  3179.     when reassignment is completed, begin
  3180. resynchronization (see \(sc\ 6.14) and:
  3181. .LP
  3182.     \(em
  3183.     if a valid TPDU is received as the result of
  3184. the resynchronization, stop the TTR timer, or
  3185. .LP
  3186.     \(em
  3187.     if TTR runs out, wait for the next event, or
  3188. .LP
  3189.     \(em
  3190.     if an N\(hyDISCONNECT indication is received, then
  3191. begin either procedure \(sc\ 6.12.3\ a) or \(sc\ 6.12.3\ b)
  3192. depending on the TTR timer.
  3193. .LP
  3194.     \fINote\fR \ \(em\ After TTR expires and while waiting for
  3195. the next event, it is suggested that the initiator set a
  3196. timer with a value equal to TWR. If this timer expires
  3197. before the next event, the initiator should begin the procedure
  3198. in \(sc\ 6.12.3\ b);
  3199. .LP
  3200.     b)
  3201.     if the TTR timer has run out, consider the transport
  3202. connection as released and freeze the reference
  3203. (see \(sc\ 6.18);
  3204. .LP
  3205.     c)
  3206.     if a DR TPDU is retained and the TTR timer has not run out,
  3207. then follow the actions in either \(sc\ 6.12.3\ a) or
  3208. \(sc\ 6.12.3\ b).
  3209. .PP
  3210. The responder shall start its TWR timer if not already started.
  3211. The arrival of the first TPDU related to the transport connection (because 
  3212. of resynchronization by the initiator) completes the reassignment after 
  3213. failure procedure. The TWR timer is stopped and the responder shall continue
  3214. with resynchronization (see \(sc\ 6.14). If reassignment does not take 
  3215. place within this time, the transport connection is considered released 
  3216. and the reference is frozen (see \(sc\ 6.18). 
  3217. .PP
  3218. If reassignment occurs successfully, both transport entities shall
  3219. continue with resynchronization.
  3220. .PP
  3221. \fINote\fR \ \(em\ The transport protocol identification procedures specified 
  3222. in Annex\ B may need to be considered in conjunction with this procedure. 
  3223. .RT
  3224. .sp 1P
  3225. .LP
  3226. 6.12.4
  3227.     \fITimers\fR 
  3228. .sp 9p
  3229. .RT
  3230. .PP
  3231. The reassignment after failure procedure uses two
  3232. timers:
  3233. .RT
  3234. .LP
  3235.     a)
  3236.     TTR, the time to try reassignment/resynchronization timer;
  3237. .LP
  3238.     b)
  3239.     TWR, the time to wait for reassignment/resynchronization
  3240. timer.
  3241. .PP
  3242. The TWR timer is used by the initiator. Its value shall not
  3243. exceed two minutes minus the sum of the maximum disconnect propagation delay
  3244. and the maximum transit delay of the network connections (see Note\ 1). The
  3245. value for the TTR timer may be indicated in the CR\ TPDU.
  3246. .PP
  3247. The TWR timer is used by the responder. If the reassignment time
  3248. parameter is present in the CR\ TPDU, the TWR timer value shall be greater 
  3249. than the sum of the TTR timer plus the maximum disconnect propagation delay 
  3250. plus the maximum transit delay of the network connections. 
  3251. .PP
  3252. If the reassignment time parameter is not present in the CR TPDU, a
  3253. default value of 2\ minutes shall be used for the TWR timer.
  3254. .PP
  3255. \fINote\ 1\fR \ \(em\ Provided that the required quality of service is 
  3256. met, TTR may be set to zero (i.e.,\ no reassignment), for example if the 
  3257. rate of 
  3258. NS\(hyprovider generated disconnects is very low.
  3259. .PP
  3260. \fINote\ 2\fR \ \(em\ Inclusion of the reassignment time parameter in the 
  3261. CR TPDU allows the responder to use a TWR value of less than 2\ minutes. 
  3262. .bp
  3263. .PP
  3264. \fINote\ 3\fR \ \(em\ If the optional TS1 and TS2 timers are used, it is
  3265. suggested:
  3266. .RT
  3267. .LP
  3268.     a)
  3269.     to stop TS1 or TS2 if running when TTR or TWR is started;
  3270. .LP
  3271.     b)
  3272.     to restart TS1 or TS2 if necessary when the corresponding
  3273. TPDU (CR\ TPDU or DR\ TPDU respectively) is repeated;
  3274. .LP
  3275.     c)
  3276.     to select for TS1 and TS2 values greater than
  3277. TTR.
  3278. .sp 2P
  3279. .LP
  3280. 6.13
  3281.     \fIRetention until acknowledgment of TPDUs\fR 
  3282. .sp 1P
  3283. .RT
  3284. .sp 1P
  3285. .LP
  3286. 6.13.1
  3287.     \fIPurpose\fR 
  3288. .sp 9p
  3289. .RT
  3290. .PP
  3291. The retention until acknowledgment of TPDUs procedure is used in
  3292. Classes\ 1, 3 and\ 4 to enable and minimize retransmission after possible loss
  3293. of TPDUs.
  3294. .PP
  3295. The confirmation of receipt variant is used only in Class\ 1 when it
  3296. has been agreed during connection establishment (see Note).
  3297. .PP
  3298. The AK variant is used in Classes\ 3 and\ 4 and also in Class\ 1 when the 
  3299. confirmation of receipt variant has not been agreed during connection 
  3300. establishment.
  3301. .PP
  3302. \fINote\fR \ \(em\ Use of confirmation of receipt variant depends on the
  3303. availability of the network layer receipt confirmation service and the 
  3304. expected cost reduction. 
  3305. .RT
  3306. .sp 1P
  3307. .LP
  3308. 6.13.2
  3309.     \fINetwork service primitives\fR 
  3310. .sp 9p
  3311. .RT
  3312. .PP
  3313. The procedure uses the following network service
  3314. primitives:
  3315. .RT
  3316. .LP
  3317.     a)
  3318.     N\(hyDATA;
  3319. .LP
  3320.     b)
  3321.     N\(hyDATA ACKNOWLEDGE.
  3322. .sp 1P
  3323. .LP
  3324. 6.13.3
  3325.     \fITPDUs and parameters used\fR 
  3326. .sp 9p
  3327. .RT
  3328. .PP
  3329. The procedure uses the following TPDUs and parameters:
  3330. .RT
  3331. .LP
  3332.     a)
  3333.     CR, CC, DR and DC TPDUs.
  3334. .LP
  3335.     b)
  3336.     RJ and AK TPDUs:
  3337. .LP
  3338.     \(em
  3339.     YR\(hyTU\(hyNR.
  3340. .LP
  3341.     c)
  3342.     DT TPDU:
  3343. .LP
  3344.     \(em
  3345.     TPDU\(hyNR.
  3346. .LP
  3347.     d)
  3348.     ED TPDU:
  3349. .LP
  3350.     \(em
  3351.     ED\(hyTPDU\(hyNR.
  3352. .LP
  3353.     e)
  3354.     EA TPDU:
  3355. .LP
  3356.     \(em
  3357.     YR\(hyEDTU\(hyNR.
  3358. .sp 1P
  3359. .LP
  3360. 6.13.4
  3361.     \fIProcedure\fR 
  3362. .sp 9p
  3363. .RT
  3364. .PP
  3365. Copies of the following TPDUs shall be retained upon transmission to permit 
  3366. their later retransmission: 
  3367. .RT
  3368. .sp 1P
  3369. .ce 1000
  3370. CR, CC, DR, DT and ED TPDUs
  3371. .ce 0
  3372. .sp 1P
  3373. .LP
  3374. except that if a DR TPDU is sent in response to a CR TPDU, there is no 
  3375. need to retain a copy of the DR\ TPDU. 
  3376. .PP
  3377. A copy of each of these TPDUs shall be retained
  3378. until:
  3379. .LP
  3380.     a)
  3381.     it is acknowledged, as specified in Table\ 5/X.224; or
  3382. .LP
  3383.     b)
  3384.     the transport connection is released.
  3385. .PP
  3386. In the confirmation of receipt variant, applicable only in
  3387. Class\ 1, transport entities shall:
  3388. .LP
  3389.     a)
  3390.     set the confirmation request parameter only if the data
  3391. parameter contains a CC or DT\ TPDU (see Notes\ 1 and\ 2); and
  3392. .LP
  3393.     b)
  3394.     issue an N\(hyDATA ACKNOWLEDGE request when it receives an
  3395. N\(hyDATA indication with the confirmation request parameter set.
  3396. .bp
  3397. .PP
  3398. \fINote\ 1\fR \ \(em\ It is a local matter for each transport entity to decide
  3399. which N\(hyDATA requests should have the confirmation request parameter 
  3400. set. This decision will normally be related to the amount of storage available 
  3401. for 
  3402. retained copies of the DT\ TPDUs.
  3403. .PP
  3404. \fINote\ 2\fR \ \(em\ Use of the confirmation request parameter may affect the
  3405. quality of network service.
  3406. .RT
  3407. .ce
  3408. \fBH.T. [T5.224]\fR 
  3409. .ce
  3410. TABLE\ 5/X.224
  3411. .ce
  3412. \fBAcknowledgement of TPDUs\fR 
  3413. .ps 9
  3414. .vs 11
  3415. .nr VS 11
  3416. .nr PS 9
  3417. .TS
  3418. center box;
  3419. lw(36p) | lw(72p) | lw(120p) .
  3420.         
  3421. .TE
  3422. .nr PS 9
  3423. .RT
  3424. .ad r
  3425. \fBTable 5/X.224 [T5.224], p.\fR 
  3426. .sp 1P
  3427. .RT
  3428. .ad b
  3429. .RT
  3430. .sp 2P
  3431. .LP
  3432. 6.14
  3433.     \fIResynchronization\fR 
  3434. .sp 1P
  3435. .RT
  3436. .sp 1P
  3437. .LP
  3438. 6.14.1
  3439.     \fIPurpose\fR 
  3440. .sp 9p
  3441. .RT
  3442. .PP
  3443. The resynchronization procedures are used in Classes\ 1 and 3 to
  3444. restore the transport connection to normal after a reset or during reassignment 
  3445. after failure according to \(sc\ 6.12. 
  3446. .RT
  3447. .sp 1P
  3448. .LP
  3449. 6.14.2
  3450.     \fINetwork service primitives\fR 
  3451. .sp 9p
  3452. .RT
  3453. .PP
  3454. The procedure makes use of the following network service
  3455. primitive:
  3456. .RT
  3457. .LP
  3458.     N\(hyRESET indication.
  3459. .sp 1P
  3460. .LP
  3461. 6.14.3
  3462.     \fITPDUs and parameters used\fR 
  3463. .sp 9p
  3464. .RT
  3465. .PP
  3466. The procedure uses the following TPDUs and parameters:
  3467. .RT
  3468. .LP
  3469.     a)
  3470.     CR, DR, CC and DC TPDUs.
  3471. .LP
  3472.     b)
  3473.     RJ TPDU:
  3474. .LP
  3475.     \(em
  3476.     YR\(hyTU\(hyNR.
  3477. .LP
  3478.     c)
  3479.     DT TPDU:
  3480. .LP
  3481.     \(em
  3482.     TPDU\(hyNR.
  3483. .LP
  3484.     d)
  3485.     ED TPDU:
  3486. .LP
  3487.     \(em
  3488.     ED\(hyTPDU\(hyNR.
  3489. .LP
  3490.     e)
  3491.     EA TPDU:
  3492. .LP
  3493.     \(em
  3494.     YR\(hyEDTU\(hyNR.
  3495. .bp
  3496. .sp 1P
  3497. .LP
  3498. 6.14.4
  3499.     \fIProcedure\fR 
  3500. .sp 9p
  3501. .RT
  3502. .PP
  3503. A transport entity which is notified of the occurrence of an
  3504. N\(hyRESET or which is performing reassignment after failure according 
  3505. to \(sc\ 6.12 shall carry out the active resynchronization procedures (see 
  3506. \(sc\ 6.14.4.1) 
  3507. \fIunless\fR any of the following hold:
  3508. .RT
  3509. .LP
  3510.     a)
  3511.     the transport entity is the responder. In this case, the
  3512. passive resynchronization procedure shall be carried out (see
  3513. \(sc\ 6.14.4.2);
  3514. .LP
  3515.     b)
  3516.     the transport entity has elected not to reassign (see
  3517. \(sc\ 6.12.3\ c)). In this case, no resynchronizaion takes
  3518. place.
  3519. .sp 1P
  3520. .LP
  3521. 6.14.4.1
  3522.     \fIActive resynchronization procedures\fR 
  3523. .sp 9p
  3524. .RT
  3525. .PP
  3526. The transport entity shall carry out one of the following
  3527. actions:
  3528. .RT
  3529. .LP
  3530.     a)
  3531.     if the TTR timer has been previously started and has run
  3532. out (i.e.\ no valid TPDU has been received), the transport
  3533. connection is considered as released and the reference is
  3534. frozen (see \(sc\ 6.18);
  3535. .LP
  3536.     b)
  3537.     otherwise, the TTR timer shall be started (unless it is
  3538. already running) and the first applicable one of the following
  3539. actions shall be taken:
  3540. .LP
  3541.     1)
  3542.     if a CR TPDU is unacknowledged, then the transport
  3543. entity shall retransmit it;
  3544. .LP
  3545.     2)
  3546.     if a DR TPDU is unacknowledged, then the transport
  3547. entity shall retransmit it;
  3548. .LP
  3549.     3)
  3550.     otherwise, the transport entity shall carry out the
  3551. data resynchronization procedures
  3552. (\(sc\ 6.14.4.3).
  3553. .LP
  3554.     The TTR timer is stopped when a valid TPDU is
  3555. received.
  3556. .sp 1P
  3557. .LP
  3558. 6.14.4.2
  3559.     \fIPassive resynchronization procedures\fR 
  3560. .sp 9p
  3561. .RT
  3562. .PP
  3563. The transport entity shall not send any TPDUs until a TPDU has been received. 
  3564. The transport entity shall start its TWR timer if it was not already started 
  3565. (due to a previous N\(hyDISCONNECT or N\(hyRESET indication). If the timer 
  3566. runs out prior to the receipt of a valid TPDU which commences resynchronization 
  3567. (i.e.\ CR or DR or ED or RJ\ TPDU), the transport connection is considered 
  3568. as 
  3569. released and the reference is released (see \(sc\ 6.18).
  3570. .PP
  3571. When a valid TPDU is received, the transport entity shall stop its TWR 
  3572. timer and carry out the appropriate one of the following actions, depending 
  3573. on the TPDU: 
  3574. .RT
  3575. .LP
  3576.     a)
  3577.     if it is a DR TPDU, then the transport entity shall send a
  3578. DC TPDU;
  3579. .LP
  3580.     b)
  3581.     if it is a repeated CR TPDU (see Note\ 1) then the transport
  3582. entity shall carry out the action which is appropriate
  3583. from the following:
  3584. .LP
  3585.     1)
  3586.     if a CC TPDU has alredy been sent, and acknowledged:
  3587. treat as a protocol error;
  3588. .LP
  3589.     2)
  3590.     if a DR TPDU is unacknowledged (whether or not a
  3591. CC\ TPDU is unacknowledged): retransmit the DR\ TPDU,
  3592. but setting the source reference to zero;
  3593. .LP
  3594.     3)
  3595.     if the T\(hyCONNECT response has not yet been received
  3596. from the user: take no action;
  3597. .LP
  3598.     4)
  3599.     otherwise: retransmit the CC TPDU followed by any
  3600. unacknowledged ED\ TPDU (see Note\ 2) and any
  3601. DT\ TPDU.
  3602. .LP
  3603.     \fINote\ 1\fR \ \(em\ A repeated CR can be identified by being on
  3604. a network connection with the appropriate network
  3605. addresses and having a correct source reference.
  3606. .LP
  3607.     \fINote\ 2\fR \ \(em\ The transport entity should not use network
  3608. expedited until the CC is acknowledged (see \(sc\ 6.5).
  3609. This rule prevents the network expedited from
  3610. overtaking the CC\ TPDU;
  3611. .bp
  3612. .LP
  3613.     c)
  3614.     if it is an RJ or ED TPDU, then one of the following actions
  3615. shall be taken:
  3616. .LP
  3617.     1)
  3618.     if a DR TPDU is unacknowledged, then the transport
  3619. entity shall retransmit it;
  3620. .LP
  3621.     2)
  3622.     if a CC TPDU is unacknowledged, the RJ or ED\ TPDU
  3623. shall be considered as acknowledging the CC\ TPDU, and the transport entity
  3624. shall carry out the data resynchronization procedures (\(sc\ 6.14.4.3);
  3625. .LP
  3626.     3)
  3627.      if a CC TPDU was never sent, the RJ or ED\ TPDU should be considered 
  3628. as a protocol error; 
  3629. .LP
  3630.     4)
  3631.     otherwise, the transport entity shall carry out the
  3632. data resynchronization procedures (\(sc\ 6.14.4.3.)
  3633. .sp 1P
  3634. .LP
  3635. 6.14.4.3
  3636.     \fIData resynchronization procedures\fR 
  3637. .sp 9p
  3638. .RT
  3639. .PP
  3640. The transport entity shall carry out the following actions in the following 
  3641. order: 
  3642. .RT
  3643. .LP
  3644.     a)
  3645.     (re)transmit any ED TPDU which is unacknowledged;
  3646. .LP
  3647.     b)
  3648.     transmit an RJ TPDU with YR\(hyTU\(hyNR field set to the TPDU\(hyNR
  3649. of the next expected DT TPDU;
  3650. .LP
  3651.     c)
  3652.     wait for the next TPDU from the other transport entity,
  3653. unless it has already been received. If a DR\ TPDU is received,
  3654. the transport entity shall send a DC\ TPDU, freeze the reference,
  3655. inform the TS\(hyuser of the disconnection and take no further
  3656. action [i.e.\ it shall not follow the procedures in
  3657. \(sc\ 6.14.4.3\ d)]. If an RJ\ TPDU is received, the procedures of
  3658. \(sc\ 6.14.4.3\ d) shall be followed. If an ED\ TPDU is received, the
  3659. procedures as described in \(sc\ 6.11 shall be followed. If it is a
  3660. duplicated ED\ TPDU, the transport entity shall acknowledge it
  3661. with an EA\ TPDU, discard the duplicated ED\ TPDU and wait again
  3662. for the next TPDU;
  3663. .LP
  3664.     d)
  3665.     (re)transmit any DT TPDUs which are unacknowledged,
  3666. subject to any applicable flow control procedures
  3667. (see Note).
  3668. .LP
  3669.     \fINote\fR \ \(em\ The RJ TPDU may have reduced the credit.
  3670. .sp 2P
  3671. .LP
  3672. 6.15
  3673.     \fIMultiplexing and demultiplexing\fR 
  3674. .sp 1P
  3675. .RT
  3676. .sp 1P
  3677. .LP
  3678. 6.15.1
  3679.     \fIPurpose\fR 
  3680. .sp 9p
  3681. .RT
  3682. .PP
  3683. The multiplexing and demultiplexing procedures are used in
  3684. Classes\ 2, 3 and\ 4 to allow several transport connections to share a network
  3685. connection at the same time.
  3686. .RT
  3687. .sp 1P
  3688. .LP
  3689. 6.15.2
  3690.     \fITPDUs and parameters used\fR 
  3691. .sp 9p
  3692. .RT
  3693. .PP
  3694. The procedure makes use of the following TPDUs and
  3695. parameters:
  3696. .RT
  3697. .LP
  3698.     CC, DR, DC, DT, AK, ED, EA, RJ and ER TPDUs:
  3699. .LP
  3700.     \(em
  3701.     DST\(hyREF.
  3702. .sp 1P
  3703. .LP
  3704. 6.15.3
  3705.     \fIProcedure\fR 
  3706. .sp 9p
  3707. .RT
  3708. .PP
  3709. The transport entities shall be able to send and receive on the
  3710. same network connection TPDUs belonging to different transport connections.
  3711. .PP
  3712. \fINote\ 1\fR \ \(em\ When performing demultiplexing, the transport connection 
  3713. to which the TPDUs apply is determined by the procedures defined in \(sc\ 
  3714. 6.9. 
  3715. .PP
  3716. \fINote\ 2\fR \ \(em\ Multiplexing allows the concatenation of TPDUs belonging
  3717. to different transport connections to be transferred in the same N\(hyDATA
  3718. primitive (see \(sc\ 6.4).
  3719. .RT
  3720. .sp 2P
  3721. .LP
  3722. 6.16
  3723.     \fIExplicit flow control\fR 
  3724. .sp 1P
  3725. .RT
  3726. .sp 1P
  3727. .LP
  3728. 6.16.1
  3729.     \fIPurpose\fR 
  3730. .sp 9p
  3731. .RT
  3732. .PP
  3733. The explicit flow control procedure is used in Classes\ 2, 3 and\ 4 to 
  3734. regulate the flow of DT TPDUs independently of the flow control in the 
  3735. other layers. 
  3736. .bp
  3737. .RT
  3738. .sp 1P
  3739. .LP
  3740. 6.16.2
  3741.     \fITPDUs and parameters used\fR 
  3742. .sp 9p
  3743. .RT
  3744. .PP
  3745. The procedure makes use of the following TPDUs and
  3746. parameters:
  3747. .RT
  3748. .LP
  3749.     a)
  3750.     CR, CC, AK and RJ TPDUs:
  3751. .LP
  3752.     \(em
  3753.     CDT.
  3754. .LP
  3755.     b)
  3756.     DT TPDU:
  3757. .LP
  3758.     \(em
  3759.     TPDU\(hyNR.
  3760. .LP
  3761.     c)
  3762.     AK TPDU:
  3763. .LP
  3764.     \(em
  3765.     YR\(hyTU\(hyNR;
  3766. .LP
  3767.     \(em
  3768.     subsequence number;
  3769. .LP
  3770.     \(em
  3771.     flow control confirmation.
  3772. .LP
  3773.     d)
  3774.     RJ TPDU:
  3775. .LP
  3776.     \(em
  3777.     YR\(hyTU\(hyNR.
  3778. .sp 1P
  3779. .LP
  3780. 6.16.3
  3781.     \fIProcedure\fR 
  3782. .sp 9p
  3783. .RT
  3784. .PP
  3785. The procedures differ in different classes. They are defined in the sections 
  3786. specifying the separate classes. 
  3787. .RT
  3788. .sp 2P
  3789. .LP
  3790. 6.17
  3791.     \fIChecksum\fR 
  3792. .sp 1P
  3793. .RT
  3794. .sp 1P
  3795. .LP
  3796. 6.17.1
  3797.     \fIPurpose\fR 
  3798. .sp 9p
  3799. .RT
  3800. .PP
  3801. The checksum procedure is used to detect corruption of TPDUs by the NS\(hyprovider. 
  3802. .PP
  3803. \fINote\fR \ \(em\ Although a checksum algorithm has to be adapted to the 
  3804. type of errors expected on the network connection, at present only one 
  3805. algorithm is defined. 
  3806. .RT
  3807. .sp 1P
  3808. .LP
  3809. 6.17.2
  3810.     \fITPDUs and parameters used\fR 
  3811. .sp 9p
  3812. .RT
  3813. .PP
  3814. The procedure uses the following TPDUs and parameters:
  3815. .RT
  3816. .LP
  3817.     All TPDUs:
  3818. .LP
  3819.     \(em
  3820.     checksum.
  3821. .sp 1P
  3822. .LP
  3823. 6.17.3
  3824.     \fIProcedure\fR 
  3825. .sp 9p
  3826. .RT
  3827. .PP
  3828. The checksum is used only in Class 4. It shall always be used for the CR\ 
  3829. TPDU, and shall be used for all other TPDUs unless the non\(hyuse of the 
  3830. checksum was selected during connection establishment.
  3831. .PP
  3832. The sending transport entity shall transmit TPDUs with the checksum
  3833. parameter set such that the following formulae are satisfied:
  3834. \v'6p'
  3835. .RT
  3836. .LP
  3837.     @ pile {\fIL\fR above sum above \fIi\fR =1
  3838. } @ \fIa
  3839. \di\u\fR \(== 0 (modulo 255)
  3840. .LP
  3841.     @ pile {\fIL\fR above sum above \fIi\fR =1
  3842. } @ \fIia
  3843. \di\u\fR \(== 0 (modulo 255)
  3844. .LP
  3845. .sp 1
  3846. where
  3847. .LP
  3848.     \fIi\fR     =
  3849.     number (i.e. position) of an octet within the TPDU
  3850. (see \(sc\ 13.2).
  3851. .LP
  3852.     \fIa\fR\d\fIi\fR\u    =
  3853.     value of octet in position \fIi\fR .
  3854. .LP
  3855.     \fIL\fR     =
  3856.     length of TPDU in octets.
  3857. .PP
  3858. A transport entity which receives a TPDU for a transport
  3859. connection for which the use of checksum has been agreed and which does not
  3860. satisfy the above formulae shall discard the TPDU (see also Note\ 2).
  3861. .bp
  3862. .PP
  3863. When a spurious TPDU is received and an answer is to be sent the
  3864. transport entity shall:
  3865. .RT
  3866. .LP
  3867.     a)
  3868.      if it supports the checksum algorithm and the received TPDU contains 
  3869. a checksum parameter, include a checksum parameter in the answering 
  3870. TPDU; or
  3871. .LP
  3872.     b)
  3873.     in all other cases, not include a checksum parameter in the  answering TPDU.
  3874. .PP
  3875. An entity not supporting checksum may always suppose that a
  3876. CR\ TPDU with Class\ 4 proposed is correct and therefore negotiate down to a
  3877. class lower than\ 4.
  3878. .PP
  3879. \fINote\ 1\fR \ \(em\ An efficient algorithm for determining the checksum
  3880. parameters is given in Appendix\ I.
  3881. .PP
  3882. \fINote\ 2\fR \ \(em\ If the checksum is incorrect, it is not possible to know
  3883. with certainty to which transport connection the TPDU is related; thus, 
  3884. further action may be taken for all the transport connections assigned 
  3885. to the network connection (see \(sc\ 6.9). 
  3886. .PP
  3887. \fINote\ 3\fR \ \(em\ The checksum proposed is easy to calculate and so 
  3888. will not impose a heavy burden on implementations. However, it will not 
  3889. detect insertion or loss of leading or trailing zeros and will not detect 
  3890. some octets 
  3891. misordering.
  3892. .PP
  3893. \fINote\ 4\fR \ \(em\ When a TPDU is received on a network connection, it is
  3894. never possible to know with certainty that only Class\ 4 transport connections 
  3895. use this network connection because it may be a TPDU performing 
  3896. reassignment.
  3897. .PP
  3898. Therefore the only way to check the validity is the
  3899. following:
  3900. .RT
  3901. .LP
  3902.     a)
  3903.     if the network connection is used by a Class\ 0 or Class\ 1
  3904. transport connection, there is no checksum;
  3905. .LP
  3906.     b)
  3907.     examine the TPDU code;
  3908. .LP
  3909.     c)
  3910.     deduce the fixed part length;
  3911. .LP
  3912.     d)
  3913.     from LI, deduce the variable part;
  3914. .LP
  3915.     e)
  3916.     go through parameters and if the checksum parameter is
  3917. found, then verify it;
  3918. .LP
  3919.     f
  3920. )
  3921.     if it is incorrect, then assume that transport
  3922. connection is Class\ 4 and drop it;
  3923. .LP
  3924.     g)
  3925.     if it is correct, then associate the TPDU with a transport
  3926. connection; if the transport connection uses the checksum,
  3927. it is correct; else, it must be considered as a protocol
  3928. error.
  3929. .sp 2P
  3930. .LP
  3931. 6.18
  3932.     \fIFrozen references\fR 
  3933. .sp 1P
  3934. .RT
  3935. .sp 1P
  3936. .LP
  3937. 6.18.1
  3938.     \fIPurpose\fR 
  3939. .sp 9p
  3940. .RT
  3941. .PP
  3942. This procedure is used in order to prevent re\(hyuse of a
  3943. reference while TPDUs associated with the old use of the reference may still
  3944. exist.
  3945. .RT
  3946. .sp 1P
  3947. .LP
  3948. 6.18.2
  3949.     \fIProcedure\fR 
  3950. .sp 9p
  3951. .RT
  3952. .PP
  3953. When a transport entity determines that a particular connection is released, 
  3954. it shall place the reference which it has allocated to the connection in 
  3955. a frozen state according to the procedures of the class. While frozen, 
  3956. the reference shall not be re\(hyused. 
  3957. .PP
  3958. \fINote\fR \ \(em\ The frozen reference procedure is necessary because
  3959. retransmission or misordering can cause TPDUs bearing a reference to arrive 
  3960. at an entity after it has released the connection for which it allocated 
  3961. the 
  3962. reference. Retransmission, for example, can arise when the class includes
  3963. either resynchronization (see \(sc\ 6.14) or retransmission on timeout (see
  3964. \(sc\ 6.19).
  3965. .RT
  3966. .sp 1P
  3967. .LP
  3968. 6.18.2.1
  3969.     \fIProcedure for Classes 0 and 2\fR 
  3970. .sp 9p
  3971. .RT
  3972. .PP
  3973. This Recommendation does not specify frozen reference procedures
  3974. for classes\ 0 and\ 2.
  3975. .PP
  3976. \fINote\fR \ \(em\ For consistency with the other classes, references may be
  3977. frozen as a local matter.
  3978. .bp
  3979. .RT
  3980. .sp 1P
  3981. .LP
  3982. 6.18.2.2
  3983.     \fIProcedure for Classes 1 and 3\fR 
  3984. .sp 9p
  3985. .RT
  3986. .PP
  3987. The frozen reference procedure is used except in the following
  3988. cases (see Note\ 1):
  3989. .RT
  3990. .LP
  3991.     a)
  3992.     when the transport entity receives a DC TPDU in response to
  3993. a DR TPDU which it has sent (see Note\ 2);
  3994. .LP
  3995.     b)
  3996.     when the transport entity sends a DR TPDU in response to a
  3997. CR TPDU which it has received (see Note\ 3);
  3998. .LP
  3999.     c)
  4000.     when the transport entity has considered the connection to
  4001. be released after the expiration of the TWR timer
  4002. (see Note\ 4);
  4003. .LP
  4004.     d)
  4005.     when the transport entity receives a DR or ER TPDU in
  4006. response to a CR TPDU which it has sent.
  4007. .PP
  4008. The period of time for which the reference remains frozen shall be greater 
  4009. than the TWR time. 
  4010. .PP
  4011. \fINote\ 1\fR \ \(em\ However, even in these cases, for consistency, freezing
  4012. the reference may be done as a local decision.
  4013. .PP
  4014. \fINote\ 2\fR \ \(em\ When the DC TPDU is received, it is certain that 
  4015. the other transport entity considers the connection released. 
  4016. .PP
  4017. \fINote\ 3\fR \ \(em\ When the DR or ER TPDU is sent, the peer transport 
  4018. entity has not been informed of any reference assignment and thus cannot 
  4019. possibly make use of a reference (this includes the case where a CC\ TPDU 
  4020. was sent, but was 
  4021. lost).
  4022. .PP
  4023. \fINote\ 4\fR \ \(em\ In \(sc\ 6.18.2\ c), the transport entity has already
  4024. effectively frozen the reference for an adequate period.
  4025. .RT
  4026. .sp 1P
  4027. .LP
  4028. 6.18.2.3
  4029.     \fIProcedure for Class 4\fR 
  4030. .sp 9p
  4031. .RT
  4032. .PP
  4033. The frozen reference procedure shall be used in Class 4. The
  4034. period for which the reference remains frozen shall be greater than\ \fIL\fR 
  4035. (see 
  4036. \(sc\ 12.2.1.1.6).
  4037. .RT
  4038. .sp 2P
  4039. .LP
  4040. 6.19
  4041.     \fIRetransmission on timeout\fR 
  4042. .sp 1P
  4043. .RT
  4044. .sp 1P
  4045. .LP
  4046. 6.19.1
  4047.     \fIPurpose\fR 
  4048. .sp 9p
  4049. .RT
  4050. .PP
  4051. The procedure is used in Class 4 to cope with unsignalled loss of TPDUs 
  4052. by the NS\(hyprovider. 
  4053. .RT
  4054. .sp 1P
  4055. .LP
  4056. 6.19.2
  4057.     \fITPDUs used\fR 
  4058. .sp 9p
  4059. .RT
  4060. .PP
  4061. The procedure makes use of the following TPDUs:
  4062. .RT
  4063. .sp 1P
  4064. .ce 1000
  4065. CR, CC, DR, DT, ED and AK TPDUs.
  4066. .ce 0
  4067. .sp 1P
  4068. .LP
  4069. 6.19.3
  4070.     \fIProcedure\fR 
  4071. .sp 9p
  4072. .RT
  4073. .PP
  4074. The procedure is specified in the procedures for Class 4 (see
  4075. \(sc\ 12.2.1.2\ i)).
  4076. .RT
  4077. .sp 2P
  4078. .LP
  4079. 6.20
  4080.     \fIResequencing\fR 
  4081. .sp 1P
  4082. .RT
  4083. .sp 1P
  4084. .LP
  4085. 6.20.1
  4086.     \fIPurpose\fR 
  4087. .sp 9p
  4088. .RT
  4089. .PP
  4090. The resequencing procedure is used in Class 4 to cope with
  4091. misordering of TPDUs by the NS\(hyprovider.
  4092. .RT
  4093. .sp 1P
  4094. .LP
  4095. 6.20.2
  4096.     \fITPDUs and parameters used\fR 
  4097. .sp 9p
  4098. .RT
  4099. .PP
  4100. The procedure uses the following TPDUs and parameters:
  4101. .RT
  4102. .LP
  4103.     a)
  4104.     DT TPDU:
  4105. .LP
  4106.     \(em
  4107.     TPDU\(hyNR.
  4108. .LP
  4109.     b)
  4110.     ED TPDU:
  4111. .LP
  4112.     \(em
  4113.     ED\(hyTPDU\(hyNR.
  4114. .bp
  4115. .sp 1P
  4116. .LP
  4117. 6.20.3
  4118.     \fIProcedure\fR 
  4119. .sp 9p
  4120. .RT
  4121. .PP
  4122. The procedure is specified in the procedures for Class\ 4 (see
  4123. \(sc\ 12.2.3.5).
  4124. .RT
  4125. .sp 2P
  4126. .LP
  4127. 6.21
  4128.     \fIInactivity control\fR 
  4129. .sp 1P
  4130. .RT
  4131. .sp 1P
  4132. .LP
  4133. 6.21.1
  4134.     \fIPurpose\fR 
  4135. .sp 9p
  4136. .RT
  4137. .PP
  4138. The inactivity control procedure is used in Class 4 to cope with
  4139. unsignalled termination of a network connection.
  4140. .RT
  4141. .sp 1P
  4142. .LP
  4143. 6.21.2
  4144.     \fIProcedure\fR 
  4145. .sp 9p
  4146. .RT
  4147. .PP
  4148. The procedure is specified in the procedures for Class 4 (see
  4149. \(sc\ 12.2.3.3).
  4150. .RT
  4151. .sp 2P
  4152. .LP
  4153. 6.22
  4154.     \fITreatment of\fR 
  4155. \fIprotocol errors\fR 
  4156. .sp 1P
  4157. .RT
  4158. .sp 1P
  4159. .LP
  4160. 6.22.1
  4161.     \fIPurpose\fR 
  4162. .sp 9p
  4163. .RT
  4164. .PP
  4165. The procedure for treatment of protocol errors is used in all
  4166. classes to deal with invalid TPDUs.
  4167. .RT
  4168. .sp 1P
  4169. .LP
  4170. 6.22.2
  4171.     \fITPDUs and parameters used\fR 
  4172. .sp 9p
  4173. .RT
  4174. .PP
  4175. The procedure uses the following TPDUs and parameters:
  4176. .RT
  4177. .LP
  4178.     a)
  4179.     ER TPDU:
  4180. .LP
  4181.     \(em
  4182.     reject cause;
  4183. .LP
  4184.     \(em
  4185.     invalid TPDU.
  4186. .LP
  4187.     b)
  4188.     DR TPDU:
  4189. .LP
  4190.     \(em
  4191.     reason code.
  4192. .sp 1P
  4193. .LP
  4194. 6.22.3
  4195.     \fIProcedure\fR 
  4196. .sp 9p
  4197. .RT
  4198. .PP
  4199. A transport entity that receives a TPDU that can be associated to a transport 
  4200. connection and is invalid or constitutes a protocol error (see 
  4201. \(sc\(sc\ 3.2.16 and 3.2.17) shall take one of the following actions so 
  4202. as not to 
  4203. jeopardize any other transport connections not assigned to that network
  4204. connection:
  4205. .RT
  4206. .LP
  4207.     a)
  4208.     transmitting an ER TPDU;
  4209. .LP
  4210.     b)
  4211.     resetting or closing the network connection; or
  4212. .LP
  4213.     c)
  4214.     invoking the release procedures appropriate to the
  4215. class.
  4216. .PP
  4217. Under certain circumstances it is also possible to discard the
  4218. TPDU.
  4219. .PP
  4220. If an ER TPDU is sent in Class 0, it shall contain the octets of
  4221. the invalid TPDU up to and including the octet where the error was detected
  4222. (see Notes\ 3, 4 and\ 5).
  4223. .PP
  4224. If the TPDU cannot be associated with a particular transport
  4225. connection, the transport entity shall follow the procedure in \(sc\ 6.9.
  4226. .PP
  4227. \fINote\ 1\fR \ \(em\ In general, no further action is specified for the 
  4228. receiver of the ER TPDU, but it is suggested that it initiates the release 
  4229. procedure 
  4230. appropriate to the class. If the ER\ TPDU has been received as an answer to a
  4231. CR\ TPDU, then the connection is regarded as released (see \(sc\ 6.6).
  4232. .PP
  4233. \fINote\ 2\fR \ \(em\ Care should be taken by a transport entity receiving
  4234. several invalid TPDUs or ER\ TPDUs to avoid looping if the error is generated
  4235. repeatedly.
  4236. .PP
  4237. \fINote\ 3\fR \ \(em\ If the invalid received TPDU is greater than the 
  4238. selected maximum TPDU size, it is possible that it cannot be included in 
  4239. the invalid 
  4240. TPDU parameter of the ER\ TPDU.
  4241. .PP
  4242. \fINote\ 4\fR \ \(em\ It is suggested that the sender of the ER TPDU start a
  4243. timer TS2 to ensure the release of the connection. If the timer expires, the
  4244. transport entity shall initiate the release procedures appropriate to the
  4245. class. The timer should be stopped when a DR\ TPDU or an N\(hyDISCONNECT 
  4246. indication is received. 
  4247. .PP
  4248. \fINote\ 5\fR \ \(em\ In classes other than 0, it is suggested that the 
  4249. invalid TPDU be also included in the ER\ TPDU. 
  4250. .bp
  4251. .RT
  4252. .sp 2P
  4253. .LP
  4254. 6.23
  4255.     \fISplitting and recombining\fR 
  4256. .sp 1P
  4257. .RT
  4258. .sp 1P
  4259. .LP
  4260. 6.23.1
  4261.     \fIPurpose\fR 
  4262. .sp 9p
  4263. .RT
  4264. .PP
  4265. This procedure is used only in Class\ 4 to allow a transport
  4266. connection to make use of multiple network connections to provide additional
  4267. resilience against network failure, to increase throughput, or for other
  4268. reasons.
  4269. .RT
  4270. .sp 1P
  4271. .LP
  4272. 6.23.2
  4273.     \fIProcedure\fR 
  4274. .sp 9p
  4275. .RT
  4276. .PP
  4277. When this function is being used, a transport connection may be
  4278. assigned (see \(sc\ 6.1) to multiple network connections (see Note\ 1). 
  4279. TPDUs for 
  4280. the connection may be sent over any such network connection.
  4281. .PP
  4282. If the use of Class 4 is not accepted by the remote transport entity following 
  4283. the negotiation rules, then no network connection except that over 
  4284. which the CR\ TPDU was sent may have this transport connection assigned to it.
  4285. .PP
  4286. \fINote\ 1\fR \ \(em\ The resequencing function of Class 4 (see \(sc\ 6.20) 
  4287. is used to ensure that TPDUs are processed in the correct sequence. 
  4288. .PP
  4289. \fINote\ 2\fR \ \(em\ Either transport entity may assign the connection to
  4290. further network connections of which it is the owner at any time during the
  4291. lifetime of the transport connection, provided the following constraints are
  4292. respected:
  4293. .RT
  4294. .LP
  4295.     \(em
  4296.     the initiator does not start splitting before having received the CC\ TPDU;
  4297. .LP
  4298.     \(em
  4299.     as soon as a new assignment is done, it is recommended to
  4300. send a TPDU on this network connection in order to make the remote entity 
  4301. aware of this assignment. 
  4302. .PP
  4303. \fINote\ 3\fR \ \(em\ In order to enable the detection of unsignalled network 
  4304. connection failures, a transport entity performing splitting should ensure 
  4305. that TPDUs are sent at intervals on each supporting network connection, 
  4306. for example by sending successive TPDUs on successive network connections, 
  4307. where the set of network connections is used cyclically. By monitoring 
  4308. each network connection, a transport entity may detect unsignalled network 
  4309. connection failures, 
  4310. following the inactivity procedures defined in \(sc\ 12.2.3.3. Thus, for each
  4311. network connection, no period\ I (see \(sc\ 12.2.3.1) may elapse without 
  4312. the receipt of some TPDU for some transport connection. 
  4313. .sp 2P
  4314. .LP
  4315. \fB7\fR     \fBProtocol classes\fR 
  4316. .sp 1P
  4317. .RT
  4318. .PP
  4319. Table 6/X.224 gives an overview of which elements of procedure are included 
  4320. in each class. In certain cases, the elements of procedure within 
  4321. different classes are not identical, and, for this reason, Table\ 6/X.224 
  4322. cannot be considered part of the definitive specification of the protocol. 
  4323. .RT
  4324. .sp 2P
  4325. .LP
  4326. \fB8\fR     \fBSpecification for Class 0: simple class\fR 
  4327. .sp 1P
  4328. .RT
  4329. .sp 1P
  4330. .LP
  4331. 8.1
  4332.     \fIFunctions of Class 0\fR 
  4333. .sp 9p
  4334. .RT
  4335. .PP
  4336. Class 0 is designed to have minimum functionality. It provides only the 
  4337. functions needed for connection establishment with negotiation, data 
  4338. transfer with segmenting and protocol error reporting.
  4339. .PP
  4340. Class 0 provides transport connections with flow control based on the
  4341. network service provided flow control, and disconnection based on the network 
  4342. service disconnection. 
  4343. .RT
  4344. .sp 2P
  4345. .LP
  4346. 8.2
  4347.     \fIProcedures for Class 0\fR 
  4348. .sp 1P
  4349. .RT
  4350. .sp 1P
  4351. .LP
  4352. 8.2.1
  4353.     \fIProcedures applicable at all times\fR 
  4354. .sp 9p
  4355. .RT
  4356. .PP
  4357. The transport entities shall use the following
  4358. procedures:
  4359. .RT
  4360. .LP
  4361.     a)
  4362.     TPDU transfer (see \(sc\ 6.2);
  4363. .LP
  4364.     b)
  4365.     association of TPDUs with transport connections (see
  4366. \(sc\ 6.9);
  4367. .LP
  4368.     c)
  4369.     treatment of protocol errors (see \(sc\ 6.22);
  4370. .LP
  4371.     d)
  4372.     error release (see \(sc\ 6.8).
  4373. .bp
  4374. .ce
  4375. \fBH.T. [T6.224]\fR 
  4376. .ce
  4377. TABLE\ 6/X.224
  4378. .ce
  4379. \fBAllocation of elements of procedure within classes\fR 
  4380. .ps 9
  4381. .vs 11
  4382. .nr VS 11
  4383. .nr PS 9
  4384. .TS
  4385. center box;
  4386. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4387.                             
  4388. .T&
  4389. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4390. X X X X X TPDU Transfer 6.2\                             
  4391. .T&
  4392. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4393. T{
  4394. X
  4395. X
  4396. X
  4397. X
  4398. X
  4399. Segmenting and reassembling
  4400. 6.3\ 
  4401. T}                            
  4402. .T&
  4403. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4404. T{
  4405. X
  4406. X
  4407. X
  4408. X
  4409. X
  4410. Concatenation and separation
  4411. 6.4\ 
  4412. T}                            
  4413. .T&
  4414. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4415.     T{
  4416. X
  4417. X
  4418. X
  4419. X
  4420. Connection Establishment
  4421. 6.5\ 
  4422. T}                        
  4423. .T&
  4424. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4425. T{
  4426. X
  4427. X
  4428. X
  4429. X
  4430. X
  4431. Connection Refusal
  4432. 6.6\ 
  4433. T}                            
  4434. .T&
  4435. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4436. T{
  4437. X
  4438. X
  4439. X
  4440. X
  4441. X
  4442. Normal Release
  4443. 6.7\ 
  4444. implicit
  4445. explicit
  4446. X
  4447. X
  4448. X
  4449. X
  4450. X
  4451. Error Release
  4452. 6.8\ 
  4453. T}                            
  4454. .T&
  4455. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4456. X    T{
  4457. X
  4458. Association of TPDUs with TCs
  4459. 6.9\ 
  4460. T}                        
  4461. .T&
  4462. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4463. T{
  4464. X
  4465. X
  4466. X
  4467. X
  4468. X
  4469. Data TPDU Numbering
  4470. 6.10
  4471. normal
  4472. extended
  4473. .
  4474. X
  4475. m\|\ua\d\u)\d
  4476. o\|\ua\d\u)\d
  4477. m
  4478. o
  4479. m
  4480. o
  4481. Expedited Data Transfer
  4482. 6.11
  4483. network normal
  4484. network express
  4485. .
  4486. m
  4487. ao
  4488. X\|\ua\d\u)\d
  4489. X\fR
  4490. X
  4491. Reassignment after failure
  4492. 6.12
  4493. T}                            
  4494. .T&
  4495. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4496.     X    T{
  4497. X
  4498. \uc\d\u)\d
  4499. Retention until acknowledgement of TPDUs
  4500. 6.13
  4501. Conf. receipt
  4502. AK
  4503. .
  4504. ao
  4505. m
  4506. .
  4507. X
  4508. X
  4509. Resynchronization
  4510. 6.14
  4511. T}                    
  4512. .T&
  4513. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4514.     X    T{
  4515. X
  4516. \uc\d\u)\d
  4517. Multiplexing and Demultiplexing
  4518. 6.15
  4519. T}                    
  4520. .T&
  4521. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4522.         T{
  4523. X\|\ub\d\u)\d
  4524. X
  4525. X
  4526. Explicit Flow Control (with)
  4527. .line
  4528. Explicit Flow Control (without)
  4529. .line
  4530. 6.16
  4531. .
  4532. X
  4533. X
  4534. m
  4535. o
  4536. X
  4537. X
  4538. Checksum (use of)
  4539. .line
  4540. Checksum (non\(hyuse of)
  4541. .line
  4542. 6.17
  4543. .
  4544. X
  4545. X
  4546. X
  4547. X
  4548. X
  4549. o
  4550. Frozen References
  4551. 6.18
  4552. T}                    
  4553. .T&
  4554. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4555.     X    T{
  4556. X
  4557. X
  4558. Retransmission on Timeout
  4559. 6.19
  4560. .
  4561. .
  4562. .
  4563. .
  4564. .
  4565. X
  4566. Resequencing
  4567. 6.20
  4568. T}                    
  4569. .T&
  4570. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4571.                 X Inactivity Control 6.21            
  4572. .T&
  4573. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4574.                 T{
  4575. X
  4576. Treatment of Protocol Errors
  4577. 6.22
  4578. T}            
  4579. .T&
  4580. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4581. T{
  4582. X
  4583. X
  4584. X
  4585. X
  4586. X
  4587. Splitting and Recombining
  4588. 6.23
  4589. T}                            
  4590. .T&
  4591. lw(90p) | lw(42p) | lw(54p) | lw(6p) | lw(12p) | lw(6p) | lw(12p) | lw(6p) .
  4592.                 T{
  4593. X
  4594. X:
  4595. Procedure always included in class.
  4596. .line
  4597. empty square:\ Not applicable.
  4598. .line
  4599. m:
  4600. Negotiable procedure whose implementation in equipment is
  4601. mandatory.
  4602. .line
  4603. o:
  4604. Negotiable procedure whose implementation in equipment is
  4605. optional.
  4606. .line
  4607. ao:
  4608. Negotiable procedure whose implementation in equipment is optional and where use depends on availability within the network service.
  4609. .line
  4610. \ua\d\u)\d
  4611. Not applicable in class 2 when non\(hyuse of explicit flow control
  4612. is selected.
  4613. .line
  4614. \ub\d\u)\d
  4615. Multiplexing may lead to degradation of the quality of service if the non\(hyuse of explicit flow control has been selected.
  4616. .line
  4617. \uc\d\u)\d
  4618. This function is provided in class 4 using procedures other than those used in the cross reference.
  4619. .parag
  4620. T}            
  4621. .TE
  4622. .nr PS 9
  4623. .RT
  4624. .ad r
  4625. \fBTableau 6/X.224 [T6.224], p. 8\fR 
  4626. .sp 1P
  4627. .RT
  4628. .ad b
  4629. .RT
  4630. .LP
  4631. .bp
  4632. .sp 1P
  4633. .LP
  4634. 8.2.2
  4635.     \fIConnection establishment\fR 
  4636. .sp 9p
  4637. .RT
  4638. .PP
  4639. The transport entities shall use the following
  4640. procedures:
  4641. .RT
  4642. .LP
  4643.     a)
  4644.     assignment to network connection (see \(sc\ 6.1); then
  4645. .LP
  4646.     b)
  4647.     connection establishment (see \(sc\ 6.5) and, if appropriate,
  4648. connection refusal (see \(sc\ 6.6);
  4649. .LP
  4650.     subject to the following constraints:
  4651. .LP
  4652.     c)
  4653.      the CR and CC TPDUs shall contain no parameter field other than those 
  4654. for TSAP\(hyID and maximum TPDU size; 
  4655. .LP
  4656.     d)
  4657.     the CR and CC TPDUs shall not contain a data field.
  4658. .sp 1P
  4659. .LP
  4660. 8.2.3
  4661.     \fIData transfer\fR 
  4662. .sp 9p
  4663. .RT
  4664. .PP
  4665. The transport entities shall use the segmenting and reassembling
  4666. procedure (see \(sc\ 6.3).
  4667. .RT
  4668. .sp 1P
  4669. .LP
  4670. 8.2.4
  4671.     \fIRelease\fR 
  4672. .sp 9p
  4673. .RT
  4674. .PP
  4675. The transport entities shall use the implicit variant of the normal release 
  4676. procedure (see \(sc\ 6.7). 
  4677. .PP
  4678. \fINote\fR \ \(em\ The lifetime of the transport connection is directly
  4679. correlated with the lifetime of the network connection.
  4680. .RT
  4681. .sp 2P
  4682. .LP
  4683. \fB9\fR     \fBSpecification for Class 1: basic error recovery class\fR 
  4684. .sp 1P
  4685. .RT
  4686. .sp 1P
  4687. .LP
  4688. 9.1
  4689.     \fIFunctions of Class 1\fR 
  4690. .sp 9p
  4691. .RT
  4692. .PP
  4693. Class 1 provides transport connections with flow control based on the network 
  4694. service provided flow control, error recovery, expedited data 
  4695. transfer, disconnection, and also the ability to support consecutive transport 
  4696. connections on a network connection. 
  4697. .PP
  4698. This class provides the functionality of Class 0 plus the ability to recover 
  4699. after a failure signalled by the Network Layer, without involving the TS\(hyuser. 
  4700. .RT
  4701. .sp 2P
  4702. .LP
  4703. 9.2
  4704.     \fIProcedures for Class 1\fR 
  4705. .sp 1P
  4706. .RT
  4707. .sp 1P
  4708. .LP
  4709. 9.2.1
  4710.     \fIProcedures applicable at all times\fR 
  4711. .sp 9p
  4712. .RT
  4713. .PP
  4714. The transport entities shall use the following
  4715. procedures:
  4716. .RT
  4717. .LP
  4718.     a)
  4719.     TPDU transfer (see \(sc\ 6.2);
  4720. .LP
  4721.     b)
  4722.     association of TPDU with transport connections (see \(sc\ 6.9);
  4723. .LP
  4724.     c)
  4725.     treatment of protocol errors (see \(sc\ 6.22);
  4726. .LP
  4727.     d)
  4728.     reassignment after failure (see \(sc\ 6.12);
  4729. .LP
  4730.     e)
  4731.     resynchronization (see \(sc\ 6.14), or reassignment after
  4732. failure (see \(sc\ 6.12) together with resynchronization
  4733. (see \(sc\ 6.14);
  4734. .LP
  4735.     f
  4736. )
  4737.     concatenation and separation (see \(sc\ 6.4);
  4738. .LP
  4739.     g)
  4740.     retention until acknowledgment of TPDUs (see \(sc\ 6.13); the
  4741. variant used, AK or confirmation of receipt, shall be as
  4742. selected during connection establishment (see Notes);
  4743. .LP
  4744.     h)
  4745.     frozen references (see \(sc\ 6.18).
  4746. .PP
  4747. \fINote\ 1\fR \ \(em\ The negotiation of the variant of retention until
  4748. acknowledgment of TPDUs procedure to be used over the transport connection 
  4749. has been designed such that if the initiator proposes the use of the AK 
  4750. variant 
  4751. (i.e. the mandatory implementation option), the responder has to accept 
  4752. use of this option and if the initiator proposes use of the confirmation 
  4753. of receipt 
  4754. variant the responder is entitled to select use of the AK variant.
  4755. .PP
  4756. \fINote\ 2\fR \ \(em\ The AK variant makes use of AK TPDUs to release copies 
  4757. of retained DT\ TPDUs. The CDT parameter of AK\ TPDUs in Class\ 1 is not 
  4758. significant, and is set to\ 1111. 
  4759. .PP
  4760. \fINote\ 3\fR \ \(em\ The confirmation of receipt variant is restricted 
  4761. to this class and its use depends on the availability of the network layer 
  4762. receipt 
  4763. confirmation service, and the expected cost reduction.
  4764. .bp
  4765. .RT
  4766. .sp 1P
  4767. .LP
  4768. 9.2.2
  4769.     \fIConnection establishment\fR 
  4770. .sp 9p
  4771. .RT
  4772. .PP
  4773. The transport entities shall use the following
  4774. procedures:
  4775. .RT
  4776. .LP
  4777.     a)
  4778.     assignment to network connection (see \(sc\ 6.1); then
  4779. .LP
  4780.     b)
  4781.     connection establishment (see \(sc\ 6.5) and, if appropriate,
  4782. connection refusal (see \(sc\ 6.6).
  4783. .sp 2P
  4784. .LP
  4785. 9.2.3
  4786.     \fIData transfer\fR 
  4787. .sp 1P
  4788. .RT
  4789. .sp 1P
  4790. .LP
  4791. 9.2.3.1
  4792.     \fIGeneral\fR 
  4793. .sp 9p
  4794. .RT
  4795. .PP
  4796. The sending transport entity shall use the following
  4797. procedures:
  4798. .RT
  4799. .LP
  4800.     a)
  4801.     segmenting (see \(sc\ 6.3); then
  4802. .LP
  4803.     b)
  4804.     the normal format variant of DT TPDU numbering (see
  4805. \(sc\ 6.10).
  4806. .LP
  4807.     The receiving transport entity shall use the following
  4808. procedures:
  4809. .LP
  4810.     c)
  4811.     the normal format variant of DT TPDU numbering (see \(sc\ 6.10); then
  4812. .LP
  4813.     d)
  4814.     reassembling (see \(sc\ 6.3).
  4815. .PP
  4816. \fINote\ 1\fR \ \(em\ The use of RJ TPDU during resynchronization (see
  4817. \(sc\ 6.14) can lead to retransmission. Thus, the receipt of a duplicate 
  4818. DT\ TPDU is possible; such a DT\ TPDU is discarded. 
  4819. .PP
  4820. \fINote\ 2\fR \ \(em\ It is possible to decide on a local basis to issue an
  4821. N\(hyRESET request in order to force the remote entity to carry out the
  4822. resynchronization (see \(sc\ 6.14).
  4823. .RT
  4824. .sp 1P
  4825. .LP
  4826. 9.2.3.2
  4827.     \fIExpedited data\fR 
  4828. .sp 9p
  4829. .RT
  4830. .PP
  4831. The transport entities shall use either of the network normal data or the 
  4832. network expedited variants of the expedited data transfer procedure (see 
  4833. \(sc\ 6.11) if their use has been selected during connection establishment 
  4834. (see 
  4835. Note\ 1).
  4836. .PP
  4837. The sending transport entity shall not allocate the same ED\(hyTPDU\(hyNR 
  4838. to successive ED\ TPDUs (see Notes\ 2 and\ 3). 
  4839. .PP
  4840. When acknowledging an ED\ TPDU by sending an EA\ TPDU the transport
  4841. entity shall put into the YR\(hyEDTU\(hyNR parameter of the EA\ TPDU the value
  4842. received in the ED\(hyTPDU\(hyNR parameter of the ED\ TPDU.
  4843. .PP
  4844. \fINote\ 1\fR \ \(em\ The negotiation of the variant of expedited data 
  4845. transfer procedure to be used over the transport connection has been designed 
  4846. such that if the initiator proposes the use of the network normal data 
  4847. variant (i.e.,\ the mandatory implementation option), the responder has 
  4848. to accept use of this 
  4849. option and if the initiator proposes use of the network expedited variant, 
  4850. the responder is entitled to select use of the network normal data variant. 
  4851. .PP
  4852. \fINote\ 2\fR \ \(em\ This numbering enables the receiving transport entity to
  4853. discard repeated ED TPDUs when resynchronization (see \(sc\ 6.14) has taken 
  4854. place. 
  4855. .PP
  4856. \fINote\ 3\fR \ \(em\ No other significance is attached to the ED\(hyTPDU\(hyNR
  4857. parameter. It is suggested, but not essential, that the values used be
  4858. consecutive modulo\ 128.
  4859. .RT
  4860. .sp 1P
  4861. .LP
  4862. 9.2.4
  4863.     \fIRelease\fR 
  4864. .sp 9p
  4865. .RT
  4866. .PP
  4867. The transport entities shall use the explicit variant of the
  4868. release procedure (see \(sc\ 6.7).
  4869. .RT
  4870. .sp 2P
  4871. .LP
  4872. \fB10\fR     \fBSpecification for Class 2: multiplexing class\fR 
  4873. .sp 1P
  4874. .RT
  4875. .sp 1P
  4876. .LP
  4877. 10.1
  4878.     \fIFunctions of Class 2\fR 
  4879. .sp 9p
  4880. .RT
  4881. .PP
  4882. Class 2 provides transport connections with or without individual flow 
  4883. control; no error detection or error recovery is provided. 
  4884. .PP
  4885. If the network connection resets or disconnects, the transport
  4886. connection is terminated without the transport release procedure and the
  4887. TS\(hyuser is informed.
  4888. .PP
  4889. When explicit flow control is used, a credit mechanism is defined
  4890. allowing the receiver to inform the sender of the exact amount of data he is
  4891. willing to receive and expedited data transfer is available.
  4892. .bp
  4893. .RT
  4894. .sp 2P
  4895. .LP
  4896. 10.2
  4897.     \fIProcedures for Class 2\fR 
  4898. .sp 1P
  4899. .RT
  4900. .sp 1P
  4901. .LP
  4902. 10.2.1
  4903.     \fIProcedures applicable at all times\fR 
  4904. .sp 9p
  4905. .RT
  4906. .PP
  4907. The transport entities shall use the following
  4908. procedures:
  4909. .RT
  4910. .LP
  4911.     a)
  4912.     association of TPDUs with transport connections (see
  4913. \(sc\ 6.9);
  4914. .LP
  4915.     b)
  4916.     TPDU transfer (see \(sc\ 6.2);
  4917. .LP
  4918.     c)
  4919.     treatment of protocol errors (see \(sc\ 6.22);
  4920. .LP
  4921.     d)
  4922.     concatenation and separation (see \(sc\ 6.4);
  4923. .LP
  4924.     e)
  4925.     error release (see \(sc\ 6.8).
  4926. .LP
  4927.     Additionally the transport entities may use the following
  4928. procedure:
  4929. .LP
  4930.     f
  4931. )
  4932.     multiplexing and demultiplexing (see \(sc\ 6.15).
  4933. .sp 1P
  4934. .LP
  4935. 10.2.2
  4936.     \fIConnection establishment\fR 
  4937. .sp 9p
  4938. .RT
  4939. .PP
  4940. The transport entities shall use the following
  4941. procedures:
  4942. .RT
  4943. .LP
  4944.     a)
  4945.     assignment to network connection (see \(sc\ 6.1); then
  4946. .LP
  4947.     b)
  4948.     connection establishment (see \(sc\ 6.5) and, if applicable,
  4949. connection refusal (see \(sc\ 6.6).
  4950. .sp 1P
  4951. .LP
  4952. 10.2.3
  4953.     \fIData transfer when non\(hyuse of explicit flow control has\fR 
  4954. \fIbeen selected\fR 
  4955. .sp 9p
  4956. .RT
  4957. .PP
  4958. If this option has been selected as a result of the connection
  4959. establishment, the transport entities shall use the segmenting procedure
  4960. (see \(sc\ 6.3).
  4961. .PP
  4962. The TPDU\(hyNR field of DT TPDUs is not significant and may take any
  4963. value.
  4964. .PP
  4965. \fINote\fR \ \(em\ Expedited data transfer is not applicable (see \(sc\ 6.5).
  4966. .RT
  4967. .sp 2P
  4968. .LP
  4969. 10.2.4
  4970.     \fIData transfer when use of explicit flow control has been\fR 
  4971. \fIselected\fR 
  4972. .sp 1P
  4973. .RT
  4974. .sp 1P
  4975. .LP
  4976. 10.2.4.1
  4977.     \fIGeneral\fR 
  4978. .sp 9p
  4979. .RT
  4980. .PP
  4981. The sending transport entity shall use the following
  4982. procedures:
  4983. .RT
  4984. .LP
  4985.     a)
  4986.     segmenting (see \(sc\ 6.3); then
  4987. .LP
  4988.     b)
  4989.     DT TPDU numbering (see \(sc\ 6.10);
  4990. .LP
  4991.     The receiving transport entity shall use the following
  4992. procedures:
  4993. .LP
  4994.     c)
  4995.     DT TPDU numbering (see \(sc\ 6.10); if a DT\ TPDU is received
  4996. which is out of sequence it shall be treated as a protocol error; then
  4997. .LP
  4998.     d)
  4999.     reassembling (see \(sc\ 6.3).
  5000. .PP
  5001. The variant of the DT TPDU numbering which is used by both
  5002. transport entities shall be that which was agreed at connection
  5003. establishment.
  5004. .sp 1P
  5005. .LP
  5006. 10.2.4.2
  5007.     \fIFlow control\fR 
  5008. .sp 9p
  5009. .RT
  5010. .PP
  5011. The transport entities shall send an initial credit (which may be zero) 
  5012. in the CDT field of the CR or CC TPDU. This credit represents the initial 
  5013. value of the upper window allocated to the peer entity. 
  5014. .PP
  5015. The transport entity that receives the CR or the CC TPDU shall
  5016. consider its lower window edge as zero, and its upper window edge as the 
  5017. value of the CDT field in the received TPDU. 
  5018. .PP
  5019. In order to authorize the transmission of DT TPDUs by its peer, a
  5020. transport entity may transmit an AK\ TPDU at any time, subject to the following 
  5021. constraints: 
  5022. .RT
  5023. .LP
  5024.     a)
  5025.      the YR\(hyTU\(hyNR parameter shall be at most one greater than the TPDU\(hyNR 
  5026. parameter of the last received DT\ TPDU or shall be zero if no DT\ TPDU 
  5027. has been received; 
  5028. .LP
  5029.     b)
  5030.     if an AK TPDU has previously been sent, the value of the
  5031. YR\(hyTU\(hyNR parameter shall not be lower than that in the previously sent
  5032. AK\ TPDU;
  5033. .LP
  5034.     c)
  5035.      the sum of the YR\(hyTU\(hyNR and CDT parameters shall not be less than 
  5036. the upper window edge allocated to the remote entity (see Note\ 1). 
  5037. .bp
  5038. .PP
  5039. A transport entity which receives an AK TPDU shall consider the
  5040. YR\(hyTU\(hyNR parameter as its new lower window edge, and the sum of YR\(hyTU\(hyNR 
  5041. and 
  5042. CDT as its new upper window edge. If either of these have been reduced or if
  5043. the lower window edge has become more than one greater than the TPDU\(hyNR 
  5044. of the last transmitted DT TPDU, this shall be treated as a protocol error 
  5045. (see 
  5046. \(sc\ 6.22).
  5047. .PP
  5048. A transport entity shall not send a DT TPDU with a TPDU\(hyNR outside of 
  5049. the transmit window (see Notes\ 2 and\ 3). 
  5050. .PP
  5051. \fINote\ 1\fR \ \(em\ This means that credit reduction is not applicable.
  5052. .PP
  5053. \fINote\ 2\fR \ \(em\ This means that a transport entity is required to stop
  5054. sending if the TPDU\(hyNR parameter of the next DT\ TPDU which would be 
  5055. sent would be the upper window edge. Sending of DT\ TPDU may be resumed 
  5056. if an AK\ TPDU is 
  5057. received which increases the upper window edge.
  5058. .PP
  5059. \fINote\ 3\fR \ \(em\ The rate at which a transport entity progresses the 
  5060. upper window edge allocated to its peer entity constrains the throughput 
  5061. attainable on the transport connection. 
  5062. .RT
  5063. .sp 1P
  5064. .LP
  5065. 10.2.4.3
  5066.     \fIExpedited data\fR 
  5067. .sp 9p
  5068. .RT
  5069. .PP
  5070. The transport entities shall follow the network normal data variant of 
  5071. the expedited data transfer procedure in \(sc\ 6.11 if its use has been 
  5072. agreed during connection establishment. ED and EA TPDUs are not subject 
  5073. to the flow 
  5074. control procedures in \(sc\ 10.2.4.2. The ED\(hyTPDU\(hyNR and YR\(hyEDTU\(hyNR 
  5075. parameters of ED and EA TPDUs respectively are not significant and may 
  5076. take any value. 
  5077. .RT
  5078. .sp 1P
  5079. .LP
  5080. 10.2.5
  5081.     \fIRelease\fR 
  5082. .sp 9p
  5083. .RT
  5084. .PP
  5085. The transport entities shall use the explicit variant of the
  5086. release procedure in \(sc\ 6.7.
  5087. .RT
  5088. .sp 2P
  5089. .LP
  5090. \fB11\fR     \fBSpecification for Class 3: error recovery and multiplexing
  5091. class\fR 
  5092. .sp 1P
  5093. .RT
  5094. .sp 1P
  5095. .LP
  5096. 11.1
  5097.     \fIFunctions of Class 3\fR 
  5098. .sp 9p
  5099. .RT
  5100. .PP
  5101. This class provides the functionality of Class 2 (with use of
  5102. explicit flow control) plus the ability to recover after a failure signalled
  5103. by the Network Layer without involving the TS\(hyuser.
  5104. .PP
  5105. The mechanisms used to achieve this functionality also allow the
  5106. implementation of more flexible flow control.
  5107. .RT
  5108. .sp 2P
  5109. .LP
  5110. 11.2
  5111.     \fIProcedures for Class 3\fR 
  5112. .sp 1P
  5113. .RT
  5114. .sp 1P
  5115. .LP
  5116. 11.2.1
  5117.     \fIProcedures applicable at all times\fR 
  5118. .sp 9p
  5119. .RT
  5120. .PP
  5121. The transport entities shall use the following
  5122. procedures:
  5123. .RT
  5124. .LP
  5125.     a)
  5126.     association of TPDUs with transport connections (see
  5127. \(sc\ 6.9);
  5128. .LP
  5129.     b)
  5130.     TPDU transfer (see \(sc\ 6.2) and retention until
  5131. acknowledgment of TPDUs (AK variant only) (see \(sc\ 6.13);
  5132. .LP
  5133.     c)
  5134.     treatment of protocol errors (see \(sc 6.22);
  5135. .LP
  5136.     d)
  5137.     concatenation and separation (see \(sc 6.4);
  5138. .LP
  5139.     e)
  5140.     reassignment after failure (see \(sc\ 6.12), together with
  5141. resynchronization (see \(sc\ 6.14);
  5142. .LP
  5143.     f
  5144. )
  5145.     frozen references (see \(sc\ 6.18).
  5146. .PP
  5147. Additionally, the transport entities may use the following
  5148. procedure:
  5149. .LP
  5150.     g)
  5151.     multiplexing and demultiplexing (see \(sc\ 6.15).
  5152. .sp 1P
  5153. .LP
  5154. 11.2.2
  5155.     \fIConnection establishment\fR 
  5156. .sp 9p
  5157. .RT
  5158. .PP
  5159. The transport entity shall use the following procedures:
  5160. .RT
  5161. .LP
  5162.     a)
  5163.     assignment to network connections (see \(sc\ 6.1); then
  5164. .LP
  5165.     b)
  5166.     connection establishment (see \(sc\ 6.5) and, if appropriate,
  5167. connection refusal (see \(sc\ 6.6).
  5168. .bp
  5169. .sp 2P
  5170. .LP
  5171. 11.2.3
  5172.     \fIData transfer\fR 
  5173. .sp 1P
  5174. .RT
  5175. .sp 1P
  5176. .LP
  5177. 11.2.3.1
  5178.     \fIGeneral\fR 
  5179. .sp 9p
  5180. .RT
  5181. .PP
  5182. The sending transport entity shall use the following
  5183. procedures:
  5184. .RT
  5185. .LP
  5186.     a)
  5187.     segmenting (see \(sc\ 6.3); then
  5188. .LP
  5189.     b)
  5190.      DT TPDU numbering (see \(sc\ 6.10); after receipt of an RJ\ TPDU (see 
  5191. \(sc\ 11.2.3.2) the next DT\ TPDU to be sent may have a value 
  5192. which is not the previous value of TPDU\(hyNR plus one.
  5193. .PP
  5194. The receiving transport entity shall use the following
  5195. procedures:
  5196. .LP
  5197.     c)
  5198.     DT TPDU numbering (see \(sc\ 6.10); the TPDU\(hyNR parameter of
  5199. each received DT\ TPDU shall be treated as a protocol error if it
  5200. exceeds the greatest such value received in a previous DT\ TPDU
  5201. by more than one (see Note); then
  5202. .LP
  5203.     d)
  5204.     reassembling (see \(sc\ 6.3); duplicated TPDUs shall be
  5205. eliminated before reassembling is performed.
  5206. .PP
  5207. \fINote\fR \ \(em\ The use of RJ TPDUs (see \(sc\ 11.2.3.2) can lead to
  5208. retransmission and reduction of credit. Thus the receipt of a DT\ TPDU 
  5209. which is a duplicate, or which is greater than or equal to the upper window 
  5210. edge 
  5211. allocated to the peer entity, is possible and is therefore not treated as a
  5212. protocol error.
  5213. .sp 1P
  5214. .LP
  5215. 11.2.3.2
  5216.     \fIUse of RJ TPDU\fR 
  5217. .sp 9p
  5218. .RT
  5219. .PP
  5220. A transport entity may send an RJ TPDU at any time in order to
  5221. invite retransmission or to reduce the upper window edge allocated to the 
  5222. peer entity (see Note\ 1). 
  5223. .PP
  5224. When an RJ TPDU is sent, the following constraints shall be
  5225. respected:
  5226. .RT
  5227. .LP
  5228.     a)
  5229.      the YR\(hyTU\(hyNR parameter shall be at most one greater than the greatest 
  5230. such value received in a previous DT\ TPDU, or shall be 
  5231. zero if no DT\ TPDU has yet been received (see Note\ 2);
  5232. .LP
  5233.     b)
  5234.      if an AK or RJ TPDU has previously been sent, the YR\(hyTU\(hyNR parameter 
  5235. shall not be lower than that in the previously sent 
  5236. AK or RJ\ TPDU.
  5237. .PP
  5238. When a transport entity receives an RJ\ TPDU (see Note 3):
  5239. .LP
  5240.     c)
  5241.      the next DT TPDU to be transmitted, or retransmitted, shall be that for 
  5242. which the value of the TPDU\(hyNR parameter is equal 
  5243. to the value of the YR\(hyTU\(hyNR parameter of the RJ\ TPDU;
  5244. .LP
  5245.     d)
  5246.      the sum of the values of the YR\(hyTU\(hyNR and CDT parameters of the 
  5247. RJ\ TPDU becomes the new upper window edge (see Note\ 4). 
  5248. .PP
  5249. \fINote\ 1\fR \ \(em\ An RJ TPDU can also be sent as part of the
  5250. resynchronization (see \(sc\ 6.14) and reassignment after failure (see 
  5251. \(sc\ 6.12) 
  5252. procedures.
  5253. .PP
  5254. \fINote\ 2\fR \ \(em\ It is suggested that the YR\(hyTU\(hyNR parameter 
  5255. be equal to the TPDU\(hyNR parameter of the next expected DT\ TPDU. 
  5256. .PP
  5257. \fINote\ 3\fR \ \(em\ These rules are a subset of those specified for when an
  5258. RJ\ TPDU is received during resynchronization (see \(sc\ 6.14) and reassignment
  5259. after failure (see \(sc\ 6.12).
  5260. .PP
  5261. \fINote\ 4\fR \ \(em\ This means that RJ TPDU can be used to reduce the upper
  5262. window edge allocated to the peer entity (credit reduction).
  5263. .RT
  5264. .sp 1P
  5265. .LP
  5266. 11.2.3.3
  5267.     \fIFlow control\fR 
  5268. .sp 9p
  5269. .RT
  5270. .PP
  5271. The procedures shall be as defined in \(sc\ 10.2.4.2, except
  5272. that:
  5273. .RT
  5274. .LP
  5275.     a)
  5276.     a credit reduction may lead to the reception of a DT\ TPDU
  5277. with a TPDU\(hyNR parameter whose value is not but would have been
  5278. less than the upper window edge allocated to the remote entity
  5279. prior to the credit reduction. This shall not be treated as a
  5280. protocol error;
  5281. .LP
  5282.     b)
  5283.      receipt of an AK TPDU which sets the lower window edge more than one 
  5284. greater than the TPDU\(hyNR of the last transmitted 
  5285. DT\ TPDU shall not be treated as a protocol error, provided
  5286. that all acknowledged DT\ TPDUs have been previously
  5287. transmitted (see Notes\ 1 and\ 2).
  5288. .bp
  5289. .PP
  5290. \fINote\ 1\fR \ \(em\ This can only occur during retransmission following
  5291. receipt of an RJ\ TPDU.
  5292. .PP
  5293. \fINote\ 2\fR \ \(em\ The transport entity may either continue retransmission 
  5294. as before or retransmit only those DT\ TPDUs not acknowledged by the AK\ 
  5295. TPDU. In 
  5296. either case, copies of the acknowledged DT\ TPDUs need not be retained
  5297. further.
  5298. .RT
  5299. .sp 1P
  5300. .LP
  5301. 11.2.3.4
  5302.     \fIExpedited data\fR 
  5303. .sp 9p
  5304. .RT
  5305. .PP
  5306. The transport entities shall follow the network normal data variant of 
  5307. expedited data transfer procedure in \(sc\ 6.11 if its use has been agreed 
  5308. during connection establishment.
  5309. .PP
  5310. The sending transport entity shall not allocate the same ED\(hyTPDU\(hyNR 
  5311. to successive ED\ TPDUs. 
  5312. .PP
  5313. The receiving transport entity shall transmit an EA TPDU with the same 
  5314. value in its YR\(hyEDTU\(hyNR\(hyparameter. If, and only if, this number 
  5315. is different 
  5316. from that of the previously received ED\ TPDU, shall it generate a T\(hyEXPEDITED 
  5317. DATA indication to convey the data to the TS\(hyuser (see Note\ 2). 
  5318. .PP
  5319. \fINote\ 1\fR \ \(em\ No other significance is attached to the ED\(hyTPDU\(hyNR
  5320. parameter. It is suggested, but not essential, that the values be consecutive 
  5321. modulo\ 2\uD\dlFn\fR , where\ \fIn\fR is the number of bits of the parameter. 
  5322. .PP
  5323. \fINote\ 2\fR \ \(em\ This procedure ensures that the TS\(hyuser does not 
  5324. receive 
  5325. data corresponding to the same ED\ TPDU more than once.
  5326. .RT
  5327. .sp 1P
  5328. .LP
  5329. 11.2.4
  5330.     \fIRelease\fR 
  5331. .sp 9p
  5332. .RT
  5333. .PP
  5334. The transport entities shall use the explicit variant of the
  5335. release procedure (see \(sc\ 6.7).
  5336. .RT
  5337. .LP
  5338. .rs
  5339. .sp 29P
  5340. .LP
  5341. \fBMONTAGE:\ \fR SUITE DE LA REC.\ X.224 SUR LE RSTE DE CETTE PAGE
  5342. .sp 1P
  5343. .RT
  5344. .LP
  5345. .bp
  5346.